The fix I can think of is rather messy and large, not sure whether it's worth fixing. We'd need to track the current state of the input box and look for Enter, trigger our own change, and flag that the blurring change should be swallowed if no further changes occur before the blur.

The pre-1.7 code essentially used a totally different method but had its own set of quirks and bugs that were fixed by the new design in 1.7. So we can't just go back to that.

Thanks for looking into this.

Replying to [comment:2 dmethvin]:

The fix I can think of is rather messy and large, not sure whether it's worth fixing. We'd need to track the current state of the input box and look for Enter, trigger our own change, and flag that the blurring change should be swallowed if no further changes occur before the blur.

Hmm... that's a shame. This is an important feature for input-data driven apps. If it is decided not to fix this issue in core, is this something that could be cleanly done through a plugin? Or perhaps better in a delegated event handler? I guess the main thing would be that the fix wouldn't affect other event handlers in any way.

Here is one solution, although I think you'll see why it's not a good candidate for a general fix:

http://jsfiddle.net/nV4SA/1/

To force oldIE to fire a change event we can blur/refocus the text box, but that causes the cursor to move to the beginning of the text field. Focus and blur events are also very quirky and it's not a good idea for jQuery Core to fire them, especially if the user has their own focus/blur handlers on those fields.

The other solution of firing a fake change event when Enter is pressed and then eating the one IE wants to fire when the field is blurred is even messier and requires additional bookkeeping.

Notice that there is also a "bonk" sound when Enter is pressed, neither of these solutions address that.

If you only have *one* text field you could use a solution like this, with a barely visible submit button that causes the change to fire, and eliminates the "bonk":

http://jsfiddle.net/nV4SA/2/

Again, that's not a very good general solution so I wouldn't put it in core.

Do any of those work for your case?

Oh, another option is to just fire "change" on Enter and accept that a duplicate one may fire on blur: http://jsfiddle.net/nV4SA/4/

I don't see any solution that is good enough to incorporate into jQuery. I hope one of the workarounds above is good enough for specific needs.

#12512 is a duplicate of this ticket.

After reading ticket 12512 I understand why you're reluctant to make any kind of fix. However, the whole point of jQuery is to abstract away the browser inconsistencies behind a common API (or so I was led to believe).

Since the 1.7.x series we now have significant behavior differences between how "change" behaves in IE versus Firefox or Chrome. I can work around these issues, but this feels like a slippery slope. I started using jQuery so I didn't have to worry about things like this.

As that ticket says, any "fix" I could think of came with several serious side effects. The OLD code that worked for this particular case came with several serious side effects that were much worse. If you (or anyone who lands on this page) can think of a fix without side effects please let us know and we'll reopen. Simply saying "You're not making my life easy enough!" will not help us find a solution.

@dmethvin:

What negative side effects did the old code cause? They must have been severe to warrant this regression. :(

At minimum #8157, #6319 and #8866; our faked change event was not in the right order in relation to ones like click, keydown or keyup since we piggybacked off events other than change. If you pull the code and try some patches the unit tests should let you know if you broke it.

Followup after an offline discussion with James Greene, note that IE is doing it right according to the W3C: http://jsfiddle.net/dmethvin/Mu3Kn/

"The onchange event occurs when a control loses the input focus and its value has been modified since gaining focus." -- Scripts in HTML documents (HTML4)

I don't see anything in HTML4 or HTML5 that says Enter gets special dispensation, but if anyone can find a link I'd be grateful.

Neither Chrome nor Firefox currently fire blur when the Enter key is pressed, so they should not fire change either. Conceivably we could eat the change event on Enter for those browsers, but the same problems apply as conjuring one for IE (we'd have to fake-fire one on blur) so I think the current disposition is still valid.

Since Chrome and Firefox are on a quick-update cycle and seem to like conforming to standards, you could file bug reports on their trackers; if you do please post a link to their tickets here.

Hi ppl,

I optimized a bit the fix from above, now it's not setting the cursor at the beginning

http://jsfiddle.net/nV4SA/8/