Bug Tracker

Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#10818 closed bug (wontfix)

IE9 won't fire change event if value of input is changed using keyup

Reported by: marciogabe Owned by:
Priority: low Milestone: None
Component: event Version: 1.7
Keywords: ie6 ie7 ie8 ie9 ie10 Cc:
Blocked by: Blocking:

Description

If both keyup and change events are bound to same text input box, and the value of the input is changed on keyup event, the change event will not fire in IE9 + jQuery 1.7.

This used to work in IE8 + jQuery 1.6.4, but even in IE8 + jQuery 1.7 it does not work anymore.

It does work with both 1.6.4 and 1.7 in FireFox and Chrome, latest versions.

Here is a code sample:

http://jsfiddle.net/VXfAz/

To reproduce the issue just type in something in one of the three text inputs and click or tab away. The alert should pop up, and it doesn't in IE.

Problem Matrix:

jQuery 1.6.4 jQuery 1.7
Chrome OK OK
FireFox OK OK
IE 8 OK Bug
IE 9 Bug Bug

Change History (12)

comment:1 Changed 8 years ago by dmethvin

Status: newopen

Sounds related to #10636, if not the same bug.

comment:2 Changed 8 years ago by dmethvin

Component: unfiledevent
Milestone: None1.next
Priority: undecidedhigh

comment:3 in reply to:  2 Changed 8 years ago by emerson.diego.duarte@…

I had the same problem, if someone knows how to fix it, please post the solution.

comment:4 Changed 8 years ago by dmethvin

#10893 is a duplicate of this ticket.

comment:5 Changed 7 years ago by dmethvin

Keywords: ie6 ie7 ie8 ie9 added
Priority: highlow

A bit more diagnosis ... the title is correct. This can be reproduced with no jQuery at all, and definitely is triggered by the assignment to the value property:

Value referenced only: http://jsfiddle.net/VXfAz/2/

Value assigned: http://jsfiddle.net/VXfAz/3/

The reason for the regression in IE8 is that previously in IE6/7/8 we did our own change value tracking because IE didn't bubble the change event. That approach had several drawbacks so in 1.7 we switched to using IE's change event and shimming it to bubble. Since IE9 fixed their change event to bubble we didn't perform any heroics at all there which is why it is consistently broken.

comment:6 Changed 7 years ago by dmethvin

Updated broken test case with instructions: http://jsfiddle.net/VXfAz/36/

This seems to be worse now in IE10 PP4, the change event doesn't fire even if the input was not changed by the regex.

comment:7 Changed 7 years ago by konp

Same behavior in Chrome 21.0.1180.83 m, so behavior has not been changed.

Comment 4 by shin... @ google.com, Aug 17, 2011 I investigated this problem a little. Setting value in onkeyup handler overrides the memorized previous value of >the input element. After overwriting the previous value, the input value does compare the >current value and the previous value. So the input element judges the >value is not changed.

I don't know firing onchage event is the correct behavior here. Does any >one know that?

Source: http://code.google.com/p/chromium/issues/detail?id=92492

comment:8 Changed 7 years ago by dmethvin

Keywords: ie10 added
Milestone: 1.next1.9

The Chrome bug has been assigned, so I assume they'll be fixing it within a month or two.

Workaround for IE, via Tony Ross: Avoid setting via .value property, use .innerText instead. Essentially,

  // Set value for IE without clearing the "changed" flag
  this.innerText = val;
  // Set value for everyone else
  if ( this.value != val ) {
    this.value = val;
  }

comment:10 Changed 7 years ago by fracmak2

After some investigation, here's what I've found.

First off, "innerText = val" throws an exception in Chrome. It also throws an exception in IE8 when input type="button|submit|file"

Next, the performance of innerText vs value is a factor of 3x slower in IE (Firefox is faster, but that's because it's dumb and doesn't know what's going on)

http://jsperf.com/innertext-vs-value

So to fix this we would either need to set up a feature detect about innerText to decide which to use or add a try catch block on each .val(value).

Another option is to try and feature detect the bug in IE and then do a pre/post key up trap to correct for this flaw.

Both options are very complex vs the bug, and there are other event handlers and options that could be used instead of keyup (like setting a delay on keyup to set the value, or doing the innerText = val hack)

comment:11 Changed 7 years ago by dmethvin

Resolution: wontfix
Status: openclosed

Given the complexity/size of the fix and the problems in trying to get it to work in IE without breaking other browsers in the process, I think we will make this wontfix. There are workarounds possible at the application level.

comment:12 Changed 7 years ago by dmethvin

Milestone: 1.9None
Note: See TracTickets for help on using tickets.