Alternative to `blur` and `focusout` on removal

[noamr]

What is the issue with the HTML Standard?

We've removed blur on removal from the HTML standard and replaced it with "focus fixup". This is great - however in blink we find it difficult to remove that in practice due to compat issues.

There are tools that use blur (or focusout) as a signal to recompute focus, and fall back to setInterval due to the behavior in WebKit/Gecko where blur is not firing on removal.

Since bringing back synchronous events on removal is out of the question, what if we could fire a blur events in those cases, asynchronously in the update the rendering steps? It can fire on the document element, or on the nearest still connected ancestor of the removed node.

This way listening to blur events would still be a good enough indicator of focus changing, but without the crashy baggage of synchronous on-removal events.

[noamr]

Thinking of something like this:

removal steps:

• if focused, save focused element's ancestor path for later as "pending blur path"
  focusing step:
• nullify the pending blur path
  rendering update:
• if we have a pending blur path, fire blur at the lowest node in that path that's still connected, and nullify the pending blur path.

[noamr]

Some example of how people work around this today:

https://github.com/tridactyl/tridactyl/blob/f49e1c94bcd481fdc86fb219335bafc4ce0f25ab/src/content.ts#L180-L187

        elem.addEventListener("focusout", focusElem)
        // On top of blur/focusout events, we need to periodically check the
        // activeElement is the one we want because blur/focusout events aren't
        // always triggered when document.activeElement changes
        const interval = setInterval(() => {
            if (document.activeElement != elem) focusElem()
        }, 200)

[rniwa]

if we have a pending blur path, fire blur at the lowest node in that path that's still connected, and nullify the pending blur path.

What happens if the node had been moved to a different tree at that point?

[noamr]

if we have a pending blur path, fire blur at the lowest node in that path that's still connected, and nullify the pending blur path.

What happens if the node had been moved to a different tree at that point?

Possibly the lowest node in the path that's still in the main document tree?

Perhaps a cleaner alternative is to create a Range initialized at the removed element's parent. It will fall back while its ancestors are removed until it reaches something that's definitely connected at the update the rendering time, and will not care if an element is re-inserted.

(The algorithm I put here is a strawman btw, the point is to fire blur somewhere so that a11y tools that rely on that even can act)

[noamr]

Perhaps a better set of steps:

• A document has a previously focused range, a live range or null
• When removing a focused element, set previously focused range to a live range whose root is that element's parent
• At the beginning of the focusing steps, if previously focused range is not null, then fire focusout etc on that range's root (with that surviving root as relatedTarget as well) and nullify

[domfarolino]

if we have a pending blur path, fire blur at the lowest node in that path that's still connected, and nullify the pending blur path.

At first I liked firing blur at the document a little better (if another element hadn't been refocused in the meantime), since that feels less arbitrary. But if we fired it as low in the tree as we can, I suppose anyone listening for blur on the document would still hear it, and e.target would give the listener more context as to where in the tree blur took place, right? That seems pretty good.

[sorvell]

Firing blur on an element that was not blurred seems like a band-aid rather than desirable behavior. And what about the relatedTarget?

Firing focusout is maybe more reasonable but not sure it would handle the compat. issue?

It would also be nice to unify whatever happens here with how other potentially pending events are handled on removed elements. For example, blink and gecko/webkit also disagree on firing change on a removed input (see example).

[noamr]

Firing blur on an element that was not blurred seems like a band-aid rather than desirable behavior. And what about the relatedTarget?

But it was blurred in a way. At the very least it's lost its focus-within. But maybe that's more like focusout.

Firing focusout is maybe more reasonable but not sure it would handle the compat. issue?

Well I think those tools might be OK with relying on focusout? e.g. the code in this example seems to.

It would also be nice to unify whatever happens here with how other potentially pending events are handled on removed elements. For example, blink and gecko/webkit also disagree on firing change on a removed input (see example).

Oh lovely, another one... :)

[noamr]

cc @scottaohara