Have document.hasFocus() and blur/focus events reveal system-level focus

[jan-ivar]

Fixes #5049. ...to match implementations.

• At least two implementers are interested (and none opposed):
  • Already works this way in Chrome, Firefox, Edge, Safari. e.g. https://boom-bath.glitch.me/has-focus.html and https://jan-ivar.github.io/dummy/blur.html
• Tests are written and can be reviewed and commented upon at:
  • Open to writing them

---

/interaction.html ( diff )
/semantics-other.html ( diff )

[domenic]

Wow, thank you so much for tackling this! This has long been a known problem with the spec, and I'm so glad you dove in to figure out how to fix it.

My biggest issue at this point is that I don't understand some of the cases where you're adding null checks. Clarifying those would be ideal. Perhaps even with notes or examples in the spec.

[jan-ivar]

@domenic thanks for the review! Hoping to get to the remaining items in the next day or two.

[domenic]

One thing we noticed is that document.activeElement continues returning the same value even if you un-focus the window. Does this PR ensure that stays the same?

[domenic]

More generally, @a4sriniv noted several interesting things in WICG/portals#257 (comment), which I'll quote here:

• it looks like everytime we focus on a new window/tab, we actually send blur events to the previous window and the active element of the window's document
  • we don't change the activeElement of the document though
  • we also remove any of the focus styling that was previously applied
• when we focus the previous window again, we dispatch a focus event to the document's activeElement again
• if we call focus() on an element in a window that doesn't have focus, the document's activeElement is updated, but we do not dispatch a focus event
  • it doesn't get any focus styling

We don't need to capture all of this behavior in a single spec update, but let's try to make sure that every change is in the right direction. (Thus my worry about activeElement above; if this PR clears it, then that would be a bit of a regression.)

[jan-ivar]

One thing we noticed is that document.activeElement continues returning the same value even if you un-focus the window. Does this PR ensure that stays the same?

@domenic I think so, because it looks like activeElement is only affected here: "4. For each entry entry in new chain, in reverse order, run these substeps: 1. If entry is a focusable area: designate entry as the focused area of the document."

...and new chain is empty then.

The only place we appear to clear it is in the Focus fixup rule, which doesn't apply here.

[domenic]

OK, I pushed some minor tweaks to line wrapping and wording, plus added an assert in one place where it wasn't immediately obvious why we were OK without a null check. I'm happy with this now!

We should try to have some tests before merging, if at all possible. Your demo page seems like it could be converted to an automated web platform test; are you up for doing that?

[jan-ivar]

Thanks, I can take a stab at it.

[domenic]

I'm confident enough about the test work in web-platform-tests/wpt#26845 that I'll go ahead and merge this spec change. We'll work together to ensure the tests land ASAP, but I think there's no more need to hold up the spec PR.

Thanks again for the great work here on this longstanding problem.

[asankah]

🙌🏼