I have a certain situation I want to clarify for myself, and I would be glad if anyone has any experience with this issue and is willing to explain it to me.
I have a textarea that has a change event handler:
textarea.bind('change', function(event){
// do something
});
Hypothetically, what if I have some sort of a click event handler that catches all user clicks:
$(document).bind('click', function(event){
event.preventDefault();
});
Will this handler also cancel blur and change events for a textarea if a user clicks out of it with his mouse? And if it will, how can I prevent this from happening?
Update: Thank you for your answers, I can not say that I tried it, but I have a similar situation and I am trying to rule out possibilities why change is not firing on my textarea. In my case there is a change handler that doesn't work if I click on an area in which all click events are prevented by default and replaced with custom behaviour.
No, it will only prevent the default browser behavior for the 'click' event.
No, it won't.
Hypothetically, what if you just tried it? (answer: it won't, as stated just before me)
If you don't want users to be able to leave a inputfield (which sounds like strange user interaction to me), you might be able to just set focus after a blur/change event - perhaps you would need a small timeout to let the event finish first. I would not recommend it, but it's always worth a try.
Related
I have a situation where an anchor fires the 'click' event before the input, which loses the focus and fires the 'focusout' event.
To be clear, I write something in the input and then I click the anchor. I'm expecting the 'focusout' event to be written to console first and then the 'click' event.
I'm not able to reproduce this in a dummy app like in the code below, it only reproduces in the web app I'm working on, which I can't share here.
click me
<input type="text" id="t">
<script>
document.querySelector("#a").addEventListener('click', function(e) {
console.log('click');
});
document.querySelector("#t").addEventListener('focusout', function(e) {
console.log('focusout');
});
</script>
Any idea how could it be possible for anchor to fire the 'click' event first before the input firing 'focusout' event?
I'm pretty dazzled how it's actually possible... I can't see how in the world, even if I wanted to, be able to make the 'click' fire first. I checked several times the event object in watcher in Chrome dev tools and I can't see anything peculiar
I'm using latest Chrome on Windows 10
The change event doesn't fire until the input loses focus. You can use onkeypress instead.
Ironically enough, it seems like jQuery .focusout / .click conflict has the exact opposite problem as you. From what I'm reading around the web it seems like the general concesus is that the HTML specification doesn't actually specify the order of events and it is up to the browser to implement however they see fit. However, in your case I would certainly expect focusout to happen first, tho clearly it isn't. Have you tried "onblur" instead?
I found it! This is one of those things which doesn't let you sleep well.
The issue was somewhere else, in some library, there is a mousedown handler on the anchor with a e.preventDefault():
http://jsfiddle.net/vynd7kgj/
This sucks. I don't know if I should cry or laugh.
Why would you want to do something like this?
I want to create a "confirm plugin" that will fire first and ask the user if "they are sure". Just to be clear, I will be using a custom made confirm box, not a the default Window confirm() Method.
If yes then it will fire all the other events that have been bound to it. If no then it will do nothing.
A use case would be a delete button that has a separate click event bound to it, which when pressed will delete an element.
If I attach my plugin to the button then it will bind another click event and by using the events info inside $._data I can send my even to the top of the list (making it fire first), I then stop propagation (this stops the other binding firing which deletes the element). If the user clicks ok on my confirm box, I trigger a click again this time just bypass the stop stuff and it will then fire the original events
I am using a slightly modified version of https://github.com/private-face/jquery.bind-first
The only way it can access this info on an element is by using:
$._data($(this)[0]).events
I want to know how "future proof" this is as I know this changed already since 1.7. Are there any plans to officially support a similar thing.
If all else fails, I know I can just make sure that the plugin and the bindings happen first in the code, but this is not really the most flexible solution.
Using $._data is a smelly solution, hence this post. Maybe there are some fancy custom event things I can do?
The short and simple answer is not at all. Using, or more importantly relying on undocumented features is never a good idea.
It sounds like you have an XY Problem here. There are likely many other ways to achieve what you're trying to do here, and using $._data is almost certainly not the best solution.
Has anyone else run into the issue where handling a click event on a submit button for a form with preventDefault stops autocomplete from working?
To be specific it simply never prompts to save the username and password combination, I assume this is because it is triggered on a post request which doesn't occur in my case.
Can anyone think of a workaround?
PS: I have only tested in IE but am willing to bet I will see similar issues in the other browsers (will test shortly).
You have three options when altering the flow of an event:
e.preventDefault()
e.stopPropagation()
return false (calls both of the above).
Maybe trying using e.stopPropagation() instead, and see what that does for you.
Is there a way to disable/set to false the onMouseUp event in javascript so that when a button is clicked it fires on mousedown by default?
Aside from the fact that onmousedown happens before onmouseup, you can't prevent an event from happening. You can however prevent default behavior of an event by executing "preventDefault()" on the event object itself.
No.
To be honest, I very much suspect there's a better way of achieving what you're after. I suspect if you update your question with some more surrounding information you'll get some good advice. :-)
I am binding an event to a checkbox's change or click event which works fine in Firefox but in IE I have to click anywhere else (causing the blur) event before the event is fired.
I have read and believe this is down to the way IE fires the events, but is there anyway I can get round it?
The whole point is that it is a smooth search feature which doesn't need a search button to be clicked
$('#sidebar .itemSearchModule-Form input[type=checkbox]').click(function() {
$('#sidebar .itemSearchModule-Form .saveButton').click();
});
The change event requires a blur to happen first. The Click event should not. You could always force a blur event if you wanted by $(elem).blur()
Paolo Bergantino was right so this answer credit should go to him.
It seems my code was all screwed up and another selector was getting tied up with the sample I used above.
The CLICK event does work in IE I can confirm, if you are suffering the same problem ALL I can suggest is you check your code
try giving that checkbox a class like chkbx and try:
$('.chkbx').click(function() { etc...
its just for debuggin your selector.. being sure problem is in the action. i think for IE you need to use GetElementByID.