[Web API] Element 'focus fixup' rule

[hamishwillee]

Acceptance Criteria

• The listed features are documented sufficiently on MDN
• BCD is updated
• Interactive example and data repos are updated if appropriate
• The content has been reviewed as needed

For folks helping with Firefox related documentation

• Set bugs to dev-doc-complete
• Add entry to Firefox release notes if feature is enabled in release
• Add entry to Firefox experimental features page if feature is not yet enabled in release

Features to document

Not sure yet. Probably some documentation on missing use cases not covered in docs.

This is behind pref though: dom.focus.fixup

Related Gecko bugs

https://bugzilla.mozilla.org/show_bug.cgi?id=1810077

Other

• Check content open issues to see if any pertain to the subject matter. If there are any that can be closed because of the work, do so. If there are any that can be fixed relatively quickly because of the knowledge from completing this issue and you have time, feel free to go ahead and fix them.
• Check if glossary updates are required for the feature you're documenting - whether an existing term needs to be updated or a new term should be added.
• Check if BCD update means that content pages need to have experimental markup removed or deprecated markup added (front matter tags and macros).

[hamishwillee]

Initial task: Element 'focus fixup' needs understanding if work is needed https://bugzilla.mozilla.org/show_bug.cgi?id=1810077

OK so this is related to spec change whatwg/html#8392 in response to this issue whatwg/html#8225. See 8392 link for specific changes, but you the main ones are:

• https://html.spec.whatwg.org/multipage/webappapis.html#focus-fixup-rule
• https://html.spec.whatwg.org/multipage/infrastructure.html#node-remove-focus-fixup

The way I understand this, the focused area of a document can change based on various factors:

• removal the currently focused element from the document.
• change the style of the focused element to hidden or disabled so that it is no longer eligible to be focused.

What this spec change does it make it clear what events should fire in these cases and what should end up with focus.

Looking at the spec, I think

• removal case makes the removed node's document viewport become the focused area. However the normal focusing steps are not done - i.e. the blur and change events that would normally be fired when losing focus are not sent. It isn't clear to me if focusout is still fired.
• case where changing style makes the current element no longer be focusable runs the focusing steps for that document's viewport.
  • I'm not sure what that means when you look at the focusing steps - I'd guess it means the document viewport gets focus. However the main difference w.r.t. the first case is that the element losing focus does still cause blur to be emitted, and possibly a change event.

Where does this leave us? We haven't covered this case elsewhere, so perhaps

• a note in https://developer.mozilla.org/en-US/docs/Web/API/Element/blur_event to cover the fact that this might not be emitted on losing focus if the focused element is deleted.
• Confirm whether focusout will also not be emitted in this case and add a note there too.
• Confirm what other change events might be affected.
• Confirm what gets focus in the "change style case" i.e. is it always the viewport? I can't tell - the spec is all about the new target, but I would assume that if you lose focus in this case there is no target so the view port ends up with the focus... but I don't know what that means - ie. if any focusin or focus event is sent to indicate that. Just don't know enough.
• We should confirm this order of events is still true for most cases - https://developer.mozilla.org/en-US/docs/Web/API/FocusEvent#order_of_events. We should also add the exception cases covered by this.

I think it is worth noting those things because otherwise developers might expect to always get the blur event, and that does not happen in these cases.

I am NOT sure if we need to add a BCD entry. Possibly a subfeature indicating the new behaviour on blur() and whatever changed events are affected?

[hamishwillee]

In summary, FF111 changed such that if the element style makes an element ineligible to hold focus it will now lose focus (which will move to the document body/viewport) and emit the blur event. Previously it would hold focus.

Action is to add that info to the release note, and also to update docs to reflect what happens when focus is lost - which I did in blur docs, as the most likely place people will look. I did a minor update to BCD (in discussion) because developers not sure it is worth doing.

Status

• BCD FF110 focus fixup rule on Elements browser-compat-data#19242 - closed not needed.
• Release note FF110 Relnote and Element: blur focus fixup #25670
• Docs - FF110 Relnote and Element: blur focus fixup #25670
• dev-doc-complete