Bug Tracker

Opened 12 years ago

Closed 12 years ago

#9335 closed bug (wontfix)

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/

Change History (8)

comment:1 Changed 12 years ago by Rick Waldron

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

comment:2 Changed 12 years ago by [email protected]

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.

comment:3 Changed 12 years ago by Timmy Willison

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.

comment:4 Changed 12 years ago by [email protected]

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

comment:5 Changed 12 years ago by Rick Waldron

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.

comment:6 Changed 12 years ago by Rick Waldron

Keywords: needsreview added
Status: reopenedopen

comment:7 Changed 12 years ago by anonymous

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

comment:8 Changed 12 years ago by dmethvin

Keywords: needsreview removed
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.

Note: See TracTickets for help on using tickets.