Skip to main content

Bug Tracker

Side navigation

#10818 closed bug (wontfix)

Opened November 17, 2011 05:49PM UTC

Closed October 15, 2012 06:14PM UTC

Last modified November 27, 2012 05:39PM UTC

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 ||

Attachments (0)
Change History (12)

Changed November 17, 2011 07:40PM UTC by dmethvin comment:1

status: newopen

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

Changed November 17, 2011 07:41PM UTC by dmethvin comment:2

component: unfiledevent
milestone: None1.next
priority: undecidedhigh

Changed November 25, 2011 01:47PM UTC by emerson.diego.duarte@gmail.com comment:3

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

Changed November 26, 2011 02:46AM UTC by dmethvin comment:4

#10893 is a duplicate of this ticket.

Changed March 03, 2012 10:09PM UTC by dmethvin comment:5

keywords: → ie6 ie7 ie8 ie9
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.

Changed July 06, 2012 06:00PM UTC by dmethvin comment:6

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.

Changed September 05, 2012 07:07AM UTC by konp comment:7

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

Changed September 07, 2012 12:48PM UTC by dmethvin comment:8

keywords: ie6 ie7 ie8 ie9ie6 ie7 ie8 ie9 ie10
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;
  }

Changed September 11, 2012 09:00PM UTC by konp comment:9

Changed October 15, 2012 06:06PM UTC by fracmak2 comment:10

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)

Changed October 15, 2012 06:14PM UTC by dmethvin comment:11

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.

Changed November 27, 2012 05:39PM UTC by dmethvin comment:12

milestone: 1.9None