Side navigation
#14595 closed bug (migrated)
Opened November 30, 2013 04:14PM UTC
Closed October 21, 2014 12:28AM UTC
textbox not responding to keyup event in IE11
Reported by: | sylvain courcoux | Owned by: | sylvain courcoux |
---|---|---|---|
Priority: | low | Milestone: | None |
Component: | event | Version: | 1.10.2 |
Keywords: | ie | Cc: | |
Blocked by: | Blocking: |
Description
Hi,
I have a select element and a textbox element. The textbox is wired with a keyup event handler that checks if the input is numeric using a Regex and clears any non-numeric characters. The textbox is also wired to a focus event handler to check if the value of the select element is numeric and if it's not then blur the textbox. Basically, the functionality is to enter phone numbers.
The problem is that in IE11, non-numeric characters go through whereas is Chrome and Firefox the non-numeric characters are deleted as expected. Not sure if it's a jQuery or an IE11 problem.
The jsFiddle is here: http://jsfiddle.net/R2Axp/2/
Attachments (0)
Change History (30)
Changed November 30, 2013 04:21PM UTC by comment:1
Changed December 03, 2013 12:14PM UTC by comment:2
BTW, when using jQuery 1.8 and under, the functionality works as expected in IE; it's with versions 1.9 and above that the functionality break in IE.
Changed December 03, 2013 04:39PM UTC by comment:3
Confirmed as above.
Changed December 13, 2013 09:20PM UTC by comment:4
I dug into this a little bit, and found the culprit to be a combination of element.blur(); and the .on() handler. See the following jsfiddle:
Similar to the original commenter's fiddle, on Chrome clicking on both input boxes, neither allow you to enter keys into them because they .blur(); on focus();. The console reads "test2" whenever you click the inputs (as expected). If you take out the .blur(); command, you can type in both inputs and "test1" is console.log'd on keyup, as expected.
In IE11, everything works the same way except when you have .blur() added in (like the fiddle starts with), you can still type in the input box ONLY on the input box whose event handlers were handled with a body.on() call, instead of assigning them directly (jquery.focus(fn)). Another note is that, as per the original ticket report, the keyup function does NOT get called when you input keys into the box.
Changed December 14, 2013 05:58PM UTC by comment:5
Thanks for looking into it. What's weird is that it all used to work fine in jQuery 1.8
Changed December 19, 2013 07:04PM UTC by comment:6
@cjqed: Do you mind if we assign this ticket to you?
Changed December 20, 2013 09:48PM UTC by comment:7
@timmywil Sure, I'll dive into it this weekend.
Changed December 24, 2013 05:12AM UTC by comment:8
@timmywil So I've made some headway, but before diving deeper I'd like a confirmation. See the following jsFiddle:
Given three options to assign event handlers:
$(selector).focus(function() { doSomething(); }); $(selector).on({ focus: doSomething }); $(parentSelector).on({ focus: doSomething }, selector);
Should each of these three have the same result? Right now, the third option does not leave a function attached to the focus event because (https://github.com/jquery/jquery/blob/master/src/event.js#L97) is changing the type to the delegate type (focusin, and blur to focusout). Is this the intended behavior for the third way of assigning event handlers?
Changed December 30, 2013 05:50PM UTC by comment:9
Only the focusin
event bubbles according to the W3C.
http://www.w3.org/TR/DOM-Level-3-Events/#events-focusevent
Use the focusin
event if you are using delegation.
Changed January 05, 2014 01:55AM UTC by comment:10
resolution: | → notabug |
---|---|
status: | new → closed |
Yes, this is intended behavior. focusin
must be used in event delegation.
Changed January 05, 2014 03:20AM UTC by comment:11
How can this be marked as resolved when:
a) the jsfiddle clearly demonstrates the bug
b) it used to work just fine in jQuery 1.8
Something broke in jQuery 1.9 and above and this needs to be fixed.
Changed January 05, 2014 04:04AM UTC by comment:12
resolution: | notabug |
---|---|
status: | closed → reopened |
Changed January 05, 2014 04:06AM UTC by comment:13
owner: | → sylvain courcoux |
---|---|
status: | reopened → pending |
Agreed, this is not the problem.
Original, broken in IE: http://jsfiddle.net/R2Axp/2/
Working (I think): http://jsfiddle.net/R2Axp/8/
Does that seem correct?
Changed January 05, 2014 04:27AM UTC by comment:14
Well the jsFiddle in v8 solves the problem of the functionality not working by changing the code but that doesn't fix the jQuery bug. In IE, the functionality as it was originally coded in the jsFiddle breaks in jQuery 1.9+ and works with older jQuery versions and in other browsers.
Changed January 05, 2014 04:32AM UTC by comment:15
I just need confirmation that the change does seem to fix things, since the test case has a lot of moving parts.
This appears to be a consequence of us using the real DOM blur for .trigger("blur")
to fix several problems related to event order.
Changed January 05, 2014 04:42AM UTC by comment:16
Changed January 05, 2014 04:46AM UTC by comment:17
No, sorry, just realized that something else is still not working with the change on line 25: the input box should not allow for focus if the select element is not numeric.
Changed January 10, 2014 05:28PM UTC by comment:18
I am pretty sure this is the problem with DOM .blur()
being essentially async in IE (all versions up to at least 11). I do not think we can work around that but will leave the ticket open for now.
Changed January 11, 2014 07:12AM UTC by comment:19
Ok, thanks for leaving it open. If the functionality used to work in 1.8 and then stopped working in 1.9 and above them shouldn't it be fixable?
Changed January 25, 2014 09:01AM UTC by comment:20
resolution: | → invalid |
---|---|
status: | pending → closed |
Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!
Changed January 28, 2014 12:13AM UTC by comment:21
I think this bug should be reopened and fixed.
Changed January 28, 2014 12:18AM UTC by comment:22
resolution: | invalid |
---|---|
status: | closed → reopened |
If you're the anonymous in comment 20, the reason it auto-closed is that the reply wasn't from a logged in person.
Changed January 28, 2014 12:19AM UTC by comment:23
status: | reopened → open |
---|
Changed January 28, 2014 09:59AM UTC by comment:24
Ok, I'm the "anonymous" in comment 20 but I'm actually the person who filed the bug.
Changed January 28, 2014 09:53PM UTC by comment:25
component: | unfiled → event |
---|---|
keywords: | → ie |
priority: | undecided → low |
N.B, all versions of IE from IE6 upward fire the event asynchronously to the calling of the DOM focus or blur methods.
What you want to see in the console:
before focusing text1 focus text1 after focusing text1
What you see in IE:
before focusing text1 after focusing text1 focus text1
The reason this used to work is because we faked the focus ourselves, which caused a larger stack of bugs related to event order. See #14359, #13026, and #12868.
Changed January 30, 2014 03:25AM UTC by comment:26
I can see why this is going to be hard to handle...
Changed January 30, 2014 03:39AM UTC by comment:27
This might sound a bit of a hack but adding a setTimeout of 1ms for IE reorders the events correctly. So if the jQuery .focus() and .blur() functions could just wait 1ms before returning then that might fix this problem.
Changed January 30, 2014 03:52AM UTC by comment:28
Yes, your code can do that. Our unit tests do that. jQuery cannot do that internally without pushing the problem to another location. The caller could assume that when $(elem).focus()
returns the element is focused and it did whatever the event handler was supposed to do. That's why faking the focus event worked, although it had other undesirable effects, because we forced the handler to run right then and there.
The bottom line is that focus/blur is not an event to be trusted. It's async in IE and occasionally unreliable in Firefox as well. Don't create complicated scenarios with it. It will break.
Changed January 30, 2014 04:13AM UTC by comment:29
It's really unfortunate because the blur and focus events are used in forms and forms are used for important tasks such as user registration or e-commerce processing.
In my particular case, the functionality in the jsFiddle is used to enter international phone numbers: if the user hasn't selected a country code from the select element then it blurs the phone number textbox to force the user to select a prefix first.
I changed my code to make it work but it would really be nice to find a more general solution from within jQuery because inevitably this problem is causing bugs in people's websites, in particular those that were built and tested before 1.9 was released, but that have since then not been maintained.
BTW, are the keyup/keydown events subject to the same unexpected behavior?
Changed October 21, 2014 12:28AM UTC by comment:30
resolution: | → migrated |
---|---|
status: | open → closed |
Migrated to https://github.com/jquery/jquery/issues/1758
Just to clarify: the non-numeric go through in IE11 when the select element is left non-numeric.