Skip to main content

Bug Tracker

Side navigation

#9335 closed bug (wontfix)

Opened May 18, 2011 04:14PM UTC

Closed September 08, 2011 06:51PM UTC

Chrome triggers "change" on .blur()

Reported by: djesse Owned by:
Priority: low Milestone: 1.next
Component: event Version: 1.6.1
Keywords: Cc:
Blocked by: Blocking:
Description

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/

Attachments (0)
Change History (8)

Changed May 18, 2011 04:29PM UTC by rwaldron comment:1

component: unfiledevent
priority: undecidedlow
resolution: → invalid
status: newclosed

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

Changed May 18, 2011 05:41PM UTC by office@highresolution.info comment:2

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.

Changed May 18, 2011 05:53PM UTC by timmywil comment:3

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.

Changed May 18, 2011 06:07PM UTC by office@highresolution.info comment:4

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

Changed May 18, 2011 06:08PM UTC by rwaldron comment:5

resolution: invalid
status: closedreopened

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.

Changed May 18, 2011 06:08PM UTC by rwaldron comment:6

keywords: → needsreview
status: reopenedopen

Changed May 18, 2011 06:15PM UTC by anonymous comment:7

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

Changed September 08, 2011 06:51PM UTC by dmethvin comment:8

keywords: needsreview
resolution: → wontfix
status: openclosed

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.