Side navigation
#8148 closed bug (fixed)
Opened February 02, 2011 08:07PM UTC
Closed April 22, 2011 01:56AM UTC
Last modified March 13, 2012 04:30PM UTC
Change event is never triggered if another element is programmatically focused
Reported by: | scottgonzalez | Owned by: | |
---|---|---|---|
Priority: | undecided | Milestone: | 1.next |
Component: | event | Version: | 1.5 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
If the value of a text field is changed and then focus is programmatically moved to another element, the native change event is triggered, but any event handlers bound via jQuery will not be triggered.
Attachments (0)
Change History (7)
Changed February 02, 2011 08:09PM UTC by comment:1
description: | If the value of a text field is changed and then focus is programmatically moved to another element, the native change event is triggered, but any event handlers bound via jQuery will not be triggered. \ \ http://jsbin.com/elazu4/4/edit → If the value of a text field is changed and then focus is programmatically moved to another element, the native change event is triggered, but any event handlers bound via jQuery will not be triggered. \ \ http://jsbin.com/elazu4/5/edit |
---|
Changed February 02, 2011 08:37PM UTC by comment:2
component: | unfiled → event |
---|---|
keywords: | → needsreview |
Scott, I'm adding this to show that change is fired when the input receives focus again:
Changed February 02, 2011 09:40PM UTC by comment:3
_comment0: | OK, here's a bare-DOM example showing the order events are fired: \ \ http://jsbin.com/elazu4/8/edit \ \ I think what is happening here is jQuery.event.trigger sets a jQuery.event.triggered flag just before calling the native DOM <a>.focus() event. The browser fires the blur and change events DURING that process, which normally would be handled but are blocked because the flag is checked in eventHandle: \ \ https://github.com/jquery/jquery/blob/master/src/event.js#L402 \ \ https://github.com/jquery/jquery/blob/master/src/event.js#L85 \ \ It works properly if you start the process by using DOM <a>.focus() which calls the jQuery.event.handle directly, rather than $("a").focus() which calls jQuery.event.trigger. This appears to have been the way events were handled for several years afaict. → 1296684131617630 |
---|
OK, here's a bare-DOM example showing the order events are fired:
http://jsbin.com/elazu4/8/edit
I think what is happening here is jQuery.event.trigger sets a jQuery.event.triggered flag just before calling the native DOM <a>.focus() method. The browser fires the blur and change events DURING that process, which normally would be handled but are blocked because the flag is checked in eventHandle:
https://github.com/jquery/jquery/blob/master/src/event.js#L402
https://github.com/jquery/jquery/blob/master/src/event.js#L85
It works properly if you start the process by using DOM <a>.focus() which calls the jQuery.event.handle directly, rather than $("a").focus() which calls jQuery.event.trigger. This appears to have been the way events were handled for several years afaict.
Changed February 06, 2011 12:24PM UTC by comment:5
Replying to [comment:3 dmethvin]:
It works properly if you start the process by using DOM <a>.focus() which calls the jQuery.event.handle directly, rather than $("a").focus() which calls jQuery.event.trigger. This appears to have been the way events were handled for several years afaict.
The exact same issue can be seen by using
.blur()on the node itself rather than
.focus()on an other node:
$(this).blur()will fail to trigger
onchange()but
this.blur()will correctly trigger it.
Changed April 22, 2011 01:56AM UTC by comment:6
resolution: | → fixed |
---|---|
status: | new → closed |
Fixed in 1.5.2.
Changed April 22, 2011 01:57AM UTC by comment:7
keywords: | needsreview |
---|
This is the cause of http://bugs.jqueryui.com/ticket/6918