Figure out what to do with focusin/focusout #88

smaug---- · 2016-05-22T08:15:40Z

What the spec defines is actually useful behavior, but unfortunately implementations do something totally different. (and that something else happens to be rather useless.) See for example jquery/jquery#3123

@adrianba @RByers @jacobrossi @rniwa would blink/webkit/edge be interested in to fix their implementations, or should we change the spec? (I assume the latter)
There is also the option to remove the events altogether.

RByers · 2016-05-26T14:19:06Z

I don't know much about these events myself, but clearly fixing things to be interoperable one way or another is important. @dtapuska / @choniong thoughts?

dtapuska · 2016-05-26T14:37:49Z

The ordering of the events focusout & blur, focusin & focus could be made whatever we want as long as they are in pairs. The spec indicates an intermixed scenario which we don't implement.

The relevant code fires blur, focusout, DOMFocusOut and focus, focusin, DOMFocusIn.

We should probably also look at making DOMFocusOut/DOMFocusIn as legacy event mappings for focusin/focusout so that an event target doesn't actually get both.

smaug---- · 2016-05-26T17:10:04Z

Let's not talk about DOMFocusOut/In here, given that they are by all means deprecated.
But it is the ordering of focusin, focusout, blur and focus which is really odd in some engines. IE seems to have them the right way.

I tried to look for webkit bugs implementing focusin/out, but couldn't find the relevant one. That might have revealed why the behavior is so odd in webkit/blink.

The whole point of focusout/in is that they happen before blur/focus, but apparently that isn't happening, so the use cases for focusout/in are very weak.

smaug---- · 2016-06-20T10:05:21Z

The ordering of the events focusout & blur, focusin & focus could be made whatever we want as long as they are in pairs.

So that just doesn't make much sense, since, as I said
"The whole point of focusout/in is that they happen before blur/focus, but apparently that isn't happening, so the use cases for focusout/in are very weak."

@dtapuska I assume blink won't be changing its behavior? Same question to @rniwa and @jacobrossi
If so, we need to get whatever odd behavior is implemented spec'ed.

smaug---- · 2016-09-06T19:58:57Z

@adrianba @rniwa @dtapuska Do you think we should spec the rather useless ordering blink/webkit/edge now has, or would you be willing to fix implementations to follow the spec?
Or third option is to drop support for focusin/out.

dtapuska · 2016-09-07T13:28:30Z

I'm open to fixing blink. I'd like to hear from the edge team before blink would move on this. I think I'd like to see what jquery needs and provide that so they don't need to polyfill it.

smaug---- · 2016-09-07T14:05:21Z

@mgol ^

adrianba · 2016-09-07T16:07:42Z

Adding @travisleithead.

RByers · 2016-09-08T19:35:52Z

If we change blink, with the existing jQuery code continue to work or will it be broken by the change?

travisleithead · 2016-09-16T22:59:06Z

I'm definitely in favor of interop, and I'd prefer to have the right (useful) event ordering here that makes the most sense. If we're going to change to a particular new ordering then it: should be done together (all implementations) and done with minimal web compatibility fallout.

I think I'd like to see what jquery needs and provide that so they don't need to polyfill it.

Agree.

If we change blink, with the existing jQuery code continue to work or will it be broken by the change?

Good question.

smaug---- · 2016-09-20T09:56:29Z

@teddink

dtapuska · 2016-09-20T13:56:59Z

@travisleithead do you have any justification why the implementation changed between Edge and IE? I just want to understand if there were any interop concerns in this area.

smaug---- · 2016-10-07T17:28:12Z

Looks like blink doesn't fire focusin/out on Window object, even though it does fire focus/blur.

dmethvin · 2016-10-10T16:32:36Z

We discussed this issue in the jQuery core team meeting today and our recommendation is:

Browsers should use the standards-mandated event order: focusout, focusin, blur, focus. Since focusout and focusin are cancellable they need to happen before focus/blur to prevent take-backsies.
Browsers must provide some feature detect so that developers can know if focusin/out are implemented. Ideally this would be done at the same time as the first point so developers could know that the events are also implemented per-spec. At the moment we don't know of any reliable feature detect for these events.

The only thing jQuery guarantees right now is that focusin happens before focus and focusout happens before blur. Only IE11 has a reliable way to detect the events so jQuery simulates them even when the browser has them, which would be bad except that nobody seems to implement them correctly anyway. Once there is a reliable feature detect jQuery can defer to the working browser implementation.

smaug---- · 2016-10-10T16:36:50Z

focusin/out are not cancelable in the latest UIEvents spec.

timmywil · 2016-10-10T16:43:09Z

Another reason we like the spec order is related to something that's already been mentioned. We've had several tickets over the years about things like .is(':focus') not matching in a focus handler. It would be nice to have a handler for when the element is about to receive focus and one for when it has received focus. The spec handles that well.

markelog · 2016-10-10T16:45:07Z

Also see current state of impl in browsers at jquery/jquery#3123 (comment)

smaug---- · 2016-10-11T13:32:52Z

More weird stuff in blink. If focus is moved in blur handler, focusout it still dispatched, but if
focus is moved in focus handler, focusin isn't dispatched.
So, in blink it is possible to have events for the same target in order: blur, focus, focusin, focusout and yet have that target focused after focusout event.

smaug---- · 2016-10-11T13:35:52Z

As of now I'm hoping to replicate most of blink's behavior in Gecko, since at least that behavior should be web compatible. But, since that model is quite odd, I'd be very happy if we all agreed to fix this and follow the model closer to what is in the current spec. Unfortunately I haven't seen much related implementation work happening in other browsers, so expectations in that aren't too high.

dtapuska · 2016-10-11T13:42:21Z

@smaug---- I'd prefer that we actually shipped something that made sense. We have written interop tests here: web-platform-tests/wpt#3857 (from @sunyunjia)

We were waiting on hearing back from jquery. But it appears they were expecting cancelable events for focusin/focusout.

We are going to try to change our processing model this quarter but I'm not sure what monsters are lurking in the corners.

dmethvin · 2016-10-11T13:46:40Z

Also, focus-y events should work properly even when the browser window isn't in focus, that would be a good thing to ensure.

markelog · 2016-10-11T19:35:51Z

Perhaps you could provide a little bit of context - why it was decided to make focus(in | out) not cancelable?

dmethvin · 2016-10-11T20:00:16Z

It does seem like making them cancelable would be handy at times. Note that IE and Edge get focus management wrong when the focus leaves the window and actually prevent the user from even escaping to the browser chrome.

http://jsbin.com/kewuciyide/edit?html,output

annevk · 2018-02-27T10:37:39Z

@dtapuska any updates here?

dtapuska · 2018-02-27T16:30:29Z

We (Chrome) want to do this work although it isn't clear what interop issues we will have so it has gotten low priority. Is there new problems that this would solve which justifies a bump in priority?

annevk · 2018-02-27T17:05:42Z

@dtapuska basically, the longer we wait the less likely it becomes. It also would be good to have all focus events defined in detail to make sure that new platform features such as shadow roots interact well with them.

patricia-gallardo · 2018-09-05T09:57:19Z

Since my pull-request on uievents/order-of-events/focus-events/focus-manual.html in web-platform-tests is currently blocked because of this issue, I thought I'd chime in :)
web-platform-tests/wpt#9049 (comment)

In my testing for that change and the accompanying change in the w3c html spec:
w3c/html#278

it seems that most browsers have "naturally" converged on pretty much the same behavior which is reflected in my changes in the test. The current test only passes in IE and the behavior is not very intuitive imo. With my changes the test passes in Chrome, Firefox, Safari and almost in Edge. Since this seems to be the model the web has landed on I suggest changing the test rather than the implementers.

mgol · 2018-12-14T12:14:40Z

I re-checked browser behavior. Edge 17 & newer now matches Chrome. Firefox implemented that order as well. All dispatch the events in the following order:

blur
focusout
focus
focusin

IE 11 follows the spec order, i.e.:

focusout
focusin
blur
focus

The test case checking native behavior: https://jsfiddle.net/66znLhfw/15/

Is this still realistic to change the order when all current browsers implemented the same non-standard order?

mfreed7 · 2022-08-19T20:34:07Z

I just hit this issue (again) and I'm curious where we stand. The spec still says:

focusout
focusin
blur
focus

...but Blink, Gecko, and WebKit all do this:

blur
focusout
focus
focusin

While the specified behavior makes much more sense to me, I think that horse has left the barn, and we should likely update the spec to match the behavior. Thoughts?

The problem is described in [1]. While the spec says 'focusin' should come before 'focus', because that makes sense, implementations actually do the reverse, including Chromium. That means that developer event listeners on 'focus' can show or hide a pop-up, and that gets completed before the 'focusin' handler gets called. Then, when 'focusin' happens, the existing logic sees that focus is not in the (now showing) pop-up, decides that's a light dismiss signal, and hides the pop-up. From the developer's point of view, the pop-up never opened. With this new code, light dismiss is handled when the 'focus' event is fired, and if it isn't cancelled. [1] w3c/uievents#88 Bug: 1307772 Fixed: 1354293 Change-Id: I20373bcd8aeef24cddac5abd4548e9dc9428abf1

The problem is described in [1]. While the spec says 'focusin' should come before 'focus', because that makes sense, implementations actually do the reverse, including Chromium. That means that developer event listeners on 'focus' can show or hide a pop-up, and that gets completed before the 'focusin' handler gets called. Then, when 'focusin' happens, the existing logic sees that focus is not in the (now showing) pop-up, decides that's a light dismiss signal, and hides the pop-up. From the developer's point of view, the pop-up never opened. With this new code, light dismiss is handled when the 'focus' event is fired, and if it isn't cancelled. [1] w3c/uievents#88 Bug: 1307772 Fixed: 1354293 Change-Id: I20373bcd8aeef24cddac5abd4548e9dc9428abf1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3848846 Reviewed-by: David Baron <dbaron@chromium.org> Commit-Queue: Mason Freed <masonf@chromium.org> Auto-Submit: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#1038350}

The problem is described in [1]. While the spec says 'focusin' should come before 'focus', because that makes sense, implementations actually do the reverse, including Chromium. That means that developer event listeners on 'focus' can show or hide a pop-up, and that gets completed before the 'focusin' handler gets called. Then, when 'focusin' happens, the existing logic sees that focus is not in the (now showing) pop-up, decides that's a light dismiss signal, and hides the pop-up. From the developer's point of view, the pop-up never opened. With this new code, light dismiss is handled when the 'focus' event is fired, and if it isn't cancelled. [1] w3c/uievents#88 Bug: 1307772 Fixed: 1354293 Change-Id: I20373bcd8aeef24cddac5abd4548e9dc9428abf1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3848846 Reviewed-by: David Baron <dbaron@chromium.org> Commit-Queue: Mason Freed <masonf@chromium.org> Auto-Submit: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#1038350}

annevk · 2022-08-24T09:50:55Z

I agree that we should specify what is implemented. And then if there is sufficient interest for a change a new proposal can be made for that and evaluated separately.

Having said that, I suggest that we take this opportunity to define these events in the HTML Standard, where focus is already mostly defined anyway: whatwg/html#3514.

smaug---- · 2022-08-24T14:48:03Z

I would be very surprised if this can be changed anymore, I mean from what has been shipping for years now.

…'focusin' to 'focus', a=testonly Automatic update from web-platform-tests Move the focus-based light dismiss from 'focusin' to 'focus' The problem is described in [1]. While the spec says 'focusin' should come before 'focus', because that makes sense, implementations actually do the reverse, including Chromium. That means that developer event listeners on 'focus' can show or hide a pop-up, and that gets completed before the 'focusin' handler gets called. Then, when 'focusin' happens, the existing logic sees that focus is not in the (now showing) pop-up, decides that's a light dismiss signal, and hides the pop-up. From the developer's point of view, the pop-up never opened. With this new code, light dismiss is handled when the 'focus' event is fired, and if it isn't cancelled. [1] w3c/uievents#88 Bug: 1307772 Fixed: 1354293 Change-Id: I20373bcd8aeef24cddac5abd4548e9dc9428abf1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3848846 Reviewed-by: David Baron <dbaron@chromium.org> Commit-Queue: Mason Freed <masonf@chromium.org> Auto-Submit: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#1038350} -- wpt-commits: 1257a59c8df42427e11956d2265ba822465a938e wpt-pr: 35569

The problem is described in [1]. While the spec says 'focusin' should come before 'focus', because that makes sense, implementations actually do the reverse, including Chromium. That means that developer event listeners on 'focus' can show or hide a pop-up, and that gets completed before the 'focusin' handler gets called. Then, when 'focusin' happens, the existing logic sees that focus is not in the (now showing) pop-up, decides that's a light dismiss signal, and hides the pop-up. From the developer's point of view, the pop-up never opened. With this new code, light dismiss is handled when the 'focus' event is fired, and if it isn't cancelled. [1] w3c/uievents#88 Bug: 1307772 Fixed: 1354293 Change-Id: I20373bcd8aeef24cddac5abd4548e9dc9428abf1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3848846 Reviewed-by: David Baron <dbaron@chromium.org> Commit-Queue: Mason Freed <masonf@chromium.org> Auto-Submit: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#1038350} NOKEYCHECK=True GitOrigin-RevId: 57df05daeec7fe3dea09694854601b8b54e667af

annevk · 2023-05-10T06:36:13Z

#185 tracks moving all of this to the HTML Standard, for anyone wondering.

smaug---- mentioned this issue Oct 3, 2016

Shim focusin/focusout in all browsers? jquery/jquery#3123

Closed

chaals mentioned this issue Jan 17, 2018

Add focusin and focusout to the focus model w3c/html#278

Closed

annevk mentioned this issue Feb 27, 2018

Define all focus events whatwg/html#3514

Open

annevk mentioned this issue Sep 5, 2018

Change test to reflect change in the w3c html spec issue 278 web-platform-tests/wpt#9049

Open

lgewst mentioned this issue Oct 16, 2019

Propose the new navbeforefocus UIEvent #245

Closed

anawhj mentioned this issue Oct 16, 2019

Propose the new navbeforefocus UIEvent #246

Open

garykac added the FocusEvent label Jul 23, 2020

This was referenced Jan 23, 2021

Update focusin/focusout event order to match implementations? #276

Closed

Reflect the reality for the focus event order #290

Merged

danburzo mentioned this issue Mar 21, 2022

Update FocusEvent pages mdn/content#14127

Merged

3 tasks

chromium-wpt-export-bot mentioned this issue Aug 23, 2022

Move the focus-based light dismiss from 'focusin' to 'focus' web-platform-tests/wpt#35569

Merged

annevk mentioned this issue Aug 26, 2022

Handle Enumerate in HTMLBodyElement and HTMLFrameElement WebKit/WebKit#3520

Merged

devongovett mentioned this issue Nov 8, 2022

Make the focus fixup rule more explicit whatwg/html#8392

Merged

3 tasks

garykac closed this as completed in #290 May 9, 2023

This was referenced Sep 1, 2023

Outdated/incorrect statement about FocusEvent order mdn/content#28835

Closed

Fix 28835: Update order of dispatch for focus events mdn/content#28878

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Figure out what to do with focusin/focusout #88

Figure out what to do with focusin/focusout #88

smaug---- commented May 22, 2016

RByers commented May 26, 2016

dtapuska commented May 26, 2016

smaug---- commented May 26, 2016

smaug---- commented Jun 20, 2016

smaug---- commented Sep 6, 2016

dtapuska commented Sep 7, 2016

smaug---- commented Sep 7, 2016

adrianba commented Sep 7, 2016

RByers commented Sep 8, 2016

travisleithead commented Sep 16, 2016

smaug---- commented Sep 20, 2016

dtapuska commented Sep 20, 2016

smaug---- commented Oct 7, 2016

dmethvin commented Oct 10, 2016

smaug---- commented Oct 10, 2016

timmywil commented Oct 10, 2016

markelog commented Oct 10, 2016

smaug---- commented Oct 11, 2016

smaug---- commented Oct 11, 2016

dtapuska commented Oct 11, 2016

dmethvin commented Oct 11, 2016

markelog commented Oct 11, 2016

dmethvin commented Oct 11, 2016

annevk commented Feb 27, 2018

dtapuska commented Feb 27, 2018

annevk commented Feb 27, 2018

patricia-gallardo commented Sep 5, 2018

mgol commented Dec 14, 2018 •

edited

Loading

mfreed7 commented Aug 19, 2022

annevk commented Aug 24, 2022

smaug---- commented Aug 24, 2022

annevk commented May 10, 2023

Figure out what to do with focusin/focusout #88

Figure out what to do with focusin/focusout #88

Comments

smaug---- commented May 22, 2016

RByers commented May 26, 2016

dtapuska commented May 26, 2016

smaug---- commented May 26, 2016

smaug---- commented Jun 20, 2016

smaug---- commented Sep 6, 2016

dtapuska commented Sep 7, 2016

smaug---- commented Sep 7, 2016

adrianba commented Sep 7, 2016

RByers commented Sep 8, 2016

travisleithead commented Sep 16, 2016

smaug---- commented Sep 20, 2016

dtapuska commented Sep 20, 2016

smaug---- commented Oct 7, 2016

dmethvin commented Oct 10, 2016

smaug---- commented Oct 10, 2016

timmywil commented Oct 10, 2016

markelog commented Oct 10, 2016

smaug---- commented Oct 11, 2016

smaug---- commented Oct 11, 2016

dtapuska commented Oct 11, 2016

dmethvin commented Oct 11, 2016

markelog commented Oct 11, 2016

dmethvin commented Oct 11, 2016

annevk commented Feb 27, 2018

dtapuska commented Feb 27, 2018

annevk commented Feb 27, 2018

patricia-gallardo commented Sep 5, 2018

mgol commented Dec 14, 2018 • edited Loading

mfreed7 commented Aug 19, 2022

annevk commented Aug 24, 2022

smaug---- commented Aug 24, 2022

annevk commented May 10, 2023

mgol commented Dec 14, 2018 •

edited

Loading