Skip to main content

Bug Tracker

Side navigation

#10636 closed bug (patchwelcome)

Opened November 02, 2011 12:22PM UTC

Closed March 03, 2012 10:11PM UTC

Last modified March 10, 2012 03:22AM UTC

Inconsistent behavior with delegate and change in IE8

Reported by: Owned by:
Priority: low Milestone:
Component: event Version: 1.6.4
Keywords: needsreview Cc:
Blocked by: Blocking:

If you delegate to document both a keydown and a change handler for inputs and you press enter in an input field in IE8, the keydown handler will not be triggered for the enter-key.

I've created a reduced testcase here:

This is fixed in 1.7rc2, but when I set jsFiddle to jQuery edge (I don't know what jsfiddle is using for jquery edge), the change handler isn't fired (only the keydown one)

Attachments (0)
Change History (8)

Changed November 02, 2011 12:23PM UTC by Philip Hofstetter <> comment:1

I meant - 12 is using an even older jquery (where it's broken too)

Changed November 02, 2011 12:31PM UTC by pilif comment:2

seeing that jsfiddle's edge is actually just and seeing that current HEAD is basically not different from 1.7rc2, this means that it's really broken in 1.7 too (but differently).

Changed November 02, 2011 01:23PM UTC by pilif comment:3 is an even further reduced testcase. You really only need the input to reproduce it - no button, no form.

Changed November 02, 2011 02:30PM UTC by timmywil comment:4

component: unfiledevent
keywords: → needsreview
priority: undecidedlow
status: newopen

Unfortunately, the keydown does not bubble in IE. If the events are bound without delegation, both keydowns do fire. As for the change event, the time in which the change event fires is dependent on upon the browser. However, I see the correct output once the input is blurred.

The question is do we want to add fake bubbling for keydown?

Changed November 02, 2011 02:48PM UTC by pilif comment:5

<1.7 and 1.7 are both wrong, but they behave differently.

In jQuery <1.7, one keydown actually bubbles, but the keydown for the <Enter> key is gobbled up to simulate the change event (which other browsers fire/bubble up on Enter).

In jQuery 1.7, the keydown correctly bubbles up, but the change is not simulated any more.

As 1.7 is about to come out, the original issue is moot. What's left is a difference in events being fired on <Enter> press between browsers and IE:

See here:

Looking at the spec (, I would say that the behavior is undefined. Browsers seem to blur the element when you press enter, whereas IE decides not to. From the looks of it, both are correct.

So I'd say that the change handler rewrite you've done for 1.7 is correct and there's an implementation difference between IE and browsers.

I'm not sure whether jQuery should abstract this one away. If so, I have a patch, if you are interested. Otherwise, that's fine too.

Changed November 02, 2011 03:22PM UTC by dmethvin comment:6

Just to reiterate pilif, keydown seems to work fine in IE8. The difference is that IE doesn't fire change, delegated or not. But I can totally understand why, the Enter key doesn't blur the element so why should change fire? And since the input isn't wrapped in a form, there is no submit event to fire. Here's another test case:

Notice that if you select 1.6.4 the order of the final keydown for the Enter and the change events are reversed in IE from what they are in other browsers.

Pilif, if you'd like to provide a patch I'd consider it.

Changed November 02, 2011 03:28PM UTC by pilif comment:7

Agreed about the form thing. It's just another one of these inconsistencies between browsers.

Firefox, Safari and Chrome all fire change when you press <Enter>. IE doesn't.

This is really a question about philosophy whether jQuery should abstract this behavior or not as per the spec both are valid (the spec only says that change is fired on blur and non-IE's seem to blur and immediately focus again - <form>-tag or not)

I'm in the middle of something else right at this moment, but I'll send a pull request before noon (UTC+1) tomorrow - still. I'm not sure it's needed as this isn't exactly IE not behaving to the spec, but just the spec being inconsistent.

Changed March 03, 2012 10:11PM UTC by dmethvin comment:8

resolution: → patchwelcome
status: openclosed

Still open to a pull request on this issue but it seems like an edge case.