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:
Attachments (0)
Change History (8)
Changed May 18, 2011 04:29PM UTC by comment:1
| component: | unfiled → event |
|---|---|
| priority: | undecided → low |
| resolution: | → invalid |
| status: | new → closed |
Changed May 18, 2011 05:41PM UTC by 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 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 comment:4
I can see two events: Chrome 12/win, Chromium 11/Ubuntu ...
Changed May 18, 2011 06:08PM UTC by comment:5
| resolution: | invalid |
|---|---|
| status: | closed → reopened |
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 comment:6
| keywords: | → needsreview |
|---|---|
| status: | reopened → open |
Changed May 18, 2011 06:15PM UTC by comment:7
@rwaldron No problem. The same problem with Opera 11.10 on Windows.
Changed September 08, 2011 06:51PM UTC by comment:8
| keywords: | needsreview |
|---|---|
| resolution: | → wontfix |
| status: | open → closed |
Here's a test case that doesn't use jQuery and demonstrates the same problem on Chrome 13 Windows.
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.
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."