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
| Component: | unfiled → event |
|---|---|
| Priority: | undecided → low |
| Resolution: | → invalid |
| Status: | new → closed |
comment:2 Changed 12 years ago by
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
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:5 Changed 12 years ago by
| 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.
comment:6 Changed 12 years ago by
| Keywords: | needsreview added |
|---|---|
| Status: | reopened → open |
comment:7 Changed 12 years ago by
@rwaldron No problem. The same problem with Opera 11.10 on Windows.
comment:8 Changed 12 years ago by
| Keywords: | needsreview removed |
|---|---|
| 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."