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

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

#10893 is a duplicate of this ticket.

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.

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.

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

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

IE team is tracking this issue for IE9/10

http://connect.microsoft.com/IE/feedback/details/761843/wont-fire-change-event-if-value-of-input-is-changed-using-keyup

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)

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.