Chrome triggers "change" on .blur()

[djesse]

Chrome 11 (Win/Mac) triggers a second "change" event, when trying to .blur() the focussed input-element within the change-event callback.

Here's a testcase:  http://jsfiddle.net/djesse/TH8wk/

[rwaldron]

This is exactly as expected. Checkout:  http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-htmlevents-h3

Scroll down to the change event...

"The change event occurs when a control loses the input focus and its value has been modified since gaining focus. This event is valid for INPUT, SELECT, and TEXTAREA. element."

[office@…]

Hi,

your interpretation of the W3C spec seems to be wrong.

"The change event occurs when a control loses the input focus and its value has been modified since gaining focus. This event is valid for INPUT, SELECT, and TEXTAREA. element."

As written in the specs, an event has to be triggered when the value has changed AND (not OR !!) the focus has been removed. As the testcase shows, the .blur() method triggers a second change-event instead of a blur-event, allthough the value of the control HAS NOT changed since the first event.

So I still think, this is a bug.

[timmywil]

I'm not seeing two change events happen. It looks like the right behavior to me in the fiddle on Chrome 11.0.696.68.

[office@…]

I can see two events: Chrome 12/win, Chromium 11/Ubuntu ...

[rwaldron]

Just trying to better understand your issue after reading your latest comment. My understanding of the spec isn't flawed, I simply made a mistake in how I was assessing the test case's behaviour. Thanks for being patient and persistant.

I suspect that _something_ is causing "change" and "submit" special events to somehow double their efforts, causing the two change events... in a way that was not previously occurring.

@timmywil, I can confirm this behaviour but in Chrome 12

btw, you both just jammed me up back to back. trac is an idiot.

[anonymous]

@rwaldron No problem. The same problem with Opera 11.10 on Windows.

[dmethvin]

Here's a test case that doesn't use jQuery and demonstrates the same problem on Chrome 13 Windows.

 http://jsfiddle.net/TH8wk/3/

Given their quick development and upgrade pace it doesn't make sense for jQuery to invest time working around this somehow, since the patch will be unneeded a few months after they fix it.