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.
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 have jquery, bootstrap included in a page I'm writing. It's a complex page. The problem I'm having is with Internet Explorer not seeing mousedown event. Chrome and FF both see the event just fine but not IE.
I wrote a test page with the event and it worked just fine in IE. So my question is...
Is there a way through the developer tools to determine what is cancelling an event?
I have a suspicion that one of the many .js files I've included is cancelling the mousedown event and IE isn't seeing it anymore. Chrome and FF does though. So I'm not 100% that it's being cancelled but it's my only guess I can come up with.
Code is really irrelevant since it's all of jquery and bootstrap. However, I am playing with divs that are draggable and resizeable. That's why I need to use jquery. The bootstrap is used because I also have a wysiwyg editor on the page.
Please don't recommend click. I need mousedown. When the mouse is down the border around the draggable and resizeable div turns red and I have some code that selects that div to capture top, left, width, and height as it's being moved and resized.
If click was selected as the event, the user would have to click the div box first then click and hold to move it. That's not a user friendly interface.
Any help is greatly appreciated.
What do you exactly mean as cancel, .preventDefault() or .stopPropagation? If we are talking about preventDefault - you should still be able to add event listener to parent container and then see your event object - it might have some data to traceback. Alternative would to override jQuery .on method and see who actually subscribes to the event.
After little more thinking - add another listener BEFORE the malicious one, to do that insert document-ready handler with event binding right after jquery loading code. In your new mousedown handler try to override problematic method of the event.
UPDATE:
you should try to check all events attached to your element one by one. To do that - check this post jQuery find events handlers registered with an object
In short - try using jQuery._data( elem, "events" ); to see attached event listeners and inspect their code in your code base. After you find the reason it will be much easier to reach the desired functionality. Before that it is just a guesswork.
Since I'm creating a HTA code I'm stuck with IE :(
We needed to trap the change event in a <select> element, but guess what, IE does not support that event.
So I created a way to mimic it. With a <input type="text"> that when it is being click show the <select> just below. That part works fine. The problem is, I want to hide the select when the user click outside the select.
I tried to catch a click on the body, it works fine the first time but the second time the select gets hidden try away.
Here a simplify version of the code:
$('.product').live('click',function(){
// Show the <select id="select"> code goes here
// this is the event to close the select
$('body').die().live('click', function(){ $('#select').fadeOut(250); return;});
// get the click on the select element
$('#select').die().live('click',function(){
// kill the close the select
// THIS IS THE .die() THAT DOES NOT WORK
$('body').die();
});
Question
Is there something wrong with this code? OR is there a better way to do this? Remember I'm stuck with IE.
Internet Explorer 7 and up (and probably 6, since IE7 is mostly IE6 with lipstick, but I can't test that easily) do support the change event. Here is a jsfiddle with a really simple demo.
It's definitely true that IE does weird things with events. For example, "change" won't bubble (from <select> at least, and probably other things), but jQuery patches over that for you. Also there's the classic issue with checkboxes and radio buttons, which don't fire "change" until they lose focus (which makes it basically useless). For those, I find that "click" works fine.
In order for .die() to function correctly, the selector used with it must match exactly the selector initially used with .live().
I'm currently experiencing click events intermittently not firing. Anyone else ever had this problem?
Code is simple:
<ul class="iconButtons ui-widget ui-helper-clearfix">
<li class="ui-state-default ui-corner-all" title="Save">
<span class="btnSave ui-icon ui-icon-disk"></span>
</li>
</ul>
$(document).ready(function() {
$(".btnSave").click(function() {
alert("Sometimes I never get called!");
});
});
Occurs frequently in all browsers. Using live demonstrates the same behaviour.
I would venture to say that there is some other complication going on to prevent what you are doing.
Here are some possibilities:
Unless you give that empty span display:block; then on some browsers it will have a width and height of 0px and be unclickable. Keep in mind just adding width and height to a span won't actually work on inline elements.
You are ajax'ing content in, and not rebinding the click handler. You can check at any time by doing $(".btnSave").data("events") in your firebug or chrome console to see the number of events to that element.
Another event is usurping your event, using the technique in #2 may help reveal this.
Your click handle is being called, but not returning the right result causing to believe it wasn't being called. Have you tried adding an alert('called') to the very top of the click handler?
Are you certain the element exists in the DOM prior to appending the click element to it? You can check by doing an alert($(".btnSave").length) at the line JUST before you bind the click handler.
I would suggest you use an anchor instead of a span for your button it will fire for sure.
Put
$(".btnSave").click(function(event){
event.preventDefault();
alert("Clicked");
});
In IE, you also have to have content inside an anchor for it to work: background image / background color/ text (maybe also with big negative text-indent)
Your code will hook up event handlers to all elements with that class that already exist when the code is called. If you add more later, they won't get the handler because, well, you haven't asked that they do. :-) Options:
You could use live instead, if you add and remove these elements dynamically. live (and the related delegate) use event delegation to watch for events rather than actually attaching the handlers to the elements in question. live uses the document itself. Since click bubbles, document sees all clicks (that aren't cancelled), and so jQuery's document-wide handler can see if the click was on a .btnSave element and fire your handler if so.
You could put your script at the bottom of the page (just before the closing </body> element), so that all of the elements are there when you hook up your handler.
You could use jQuery's ready function to ensure the DOM is ready before you hook up your handlers.
Alternately, as quoted your span is pretty darned hard to click on (what with being completely empty) unless there's some CSS giving it dimensions you haven't shown... ;-)
Update: You've said the span has dimensions, and that the handler is being hooked up fine (you didn't say how you know that). The only thing left is if something is hooking the click event on those elements and cancelling them (e.g., via stopImmediatePropagation, like this), and it happens that they're earlier in the event handler list than your handler is. It seems more likely that there's an issue hooking things up, though.
There may be many different reasons for that, eg.:
the JS code you are referring to is not executed correctly (does not bind the event in the correct moment in time), try executing it when the DOM is ready:
jQuery(function(){
// your code goes here
});
you may be creating this element dynamically (if you bind it first, then create element, then this element will not have the specific event). The solution is to use .delegate() or .live() jQuery functions.
the event may be unbound somewhere in your code. Try searching for usage of .unbind() jQuery's function within JS code (or even HTML).
It turns out the span which the click event was being added to only occupied the central part of the button's graphic. Clicking directly on the glyph always fired the event, but clicking slightly outside (although seemingly still inside the button) would not raise the event.
I hope this helps anyone else using mini JQuery buttons in the same way they are presented on the JQuery UI ThemeRoller page.
I'm running jquery-ui-1.10.3 and I'm having the same intermittent issue with .toggle buttons -- they just aren't very responsive. I think it's inherent in jquery-ui because even on their demo page the toggle button feels less-than-awesome in terms of tactile response. If I click very slowly and deliberately I can usually get the button to toggle on and off but fast clicking is very hit or miss. I've tried all the tips to speed up jquery-ui but none have worked.
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.