Intent to deprecate and remove: Stop sending blur events on element removal

[Noam Rosenthal]

Contact emails

nrose...@chromium.org, d...@chromium.org

Explainer

None

Specification

https://html.spec.whatwg.org/#dom-trees:event-blur

Summary

Currently Chromium-based browsers are the only ones that fire blur events when an element is removed from the DOM. This has recently been clarified in the spec. As part of an effort to reduce synchronous side-effects of DOM insertion & removal, this deprecation will cautiously test the impact and feasibility of aligning with the spec/other browsers on this.

Blink component

Blink>DOM

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

None

Gecko: Shipped/Shipping

WebKit: Shipped/Shipping

Web developers: No signals

Other signals:

Ergonomics

There is no new API here, only a change to an existing behavior.

Activation

N/A

Security

Shouldn't be applicable.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

None

Is this feature fully tested by web-platform-tests?

Yes

https://wpt.fyi/results/dom/nodes/insertion-removing-steps/blur-event.window.html?label=experimental&label=master&aligned

Flag name on chrome://flags

OmitBlurEventOnElementRemoval

Finch feature name

OmitBlurEventOnElementRemoval

Requires code in //chrome?

False

Tracking bug

https://g-issues.chromium.org/issues/41484175

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5128696823545856?gate=5183419526152192

This intent message was generated by Chrome Platform Status.

[Domenic Denicola]

On Fri, Mar 29, 2024 at 2:33 AM Noam Rosenthal <nrose...@chromium.org> wrote:

Contact emails

nrose...@chromium.org, d...@chromium.org

Explainer

None

A few paragraphs, including e.g. example code and how it behaves differently before/after the change, would help clarify this for web developers.

Can you specify what milestones you are planning to deprecate for, and what milestone you are planning to remove in?

 

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5128696823545856?gate=5183419526152192

This intent message was generated by Chrome Platform Status.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJn%3DMYZqb%2BD4BEuaK4HzAAy7Td6QvJZhhOuWGH3a9SHyGKMUyQ%40mail.gmail.com.

[Yoav Weiss (@Shopify)]

On top of Domenic's questions, have we tried to estimate the risk here? Even if it's Chromium-only, there could be Enterprise or embedded scenarios that somehow rely on it.

Do we know how often this blur event actually fires?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9a5fLM%3DSiOkq0xmrovf2ZANwDncBQjO0BKWvoxzFQNJg%40mail.gmail.com.

[Noam Rosenthal]

On Fri, Mar 29, 2024 at 6:33 AM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

On top of Domenic's questions, have we tried to estimate the risk here? Even if it's Chromium-only, there could be Enterprise or embedded scenarios that somehow rely on it.

Yes, and we're willing to keep the old behavior as an enterprise policy, at least temporarily.

 

Do we know how often this blur event actually fires?

 

There's no way to find out unfortunately. This event is currently fired for every removal, and there could be event listeners that handle it, but there is no way to tell if functionality builds on it, or at least I couldn't think of one (happy for suggestion). We wanted to disable it in a finch and If we decide that we would rather leave things as is, staying incompatible with Gecko/WebKi/the standard, and also keeping the quirkiness of being able to run a script synchronously while a node is removed, I'm totally OK with that, but that needs to be a conscious decision.

 

On Fri, Mar 29, 2024 at 5:28 AM Domenic Denicola <dom...@chromium.org> wrote:

On Fri, Mar 29, 2024 at 2:33 AM Noam Rosenthal <nrose...@chromium.org> wrote:

Contact emails

nrose...@chromium.org, d...@chromium.org

Explainer

None

A few paragraphs, including e.g. example code and how it behaves differently before/after the change, would help clarify this for web developers.

Sure!

Writing those here, if you think they need to be in some repo that's fine.

This will mainly affect code that uses global `focus` `blur` event listeners to track the active element, for example in a form:

```js

form.addEventListener("focus", () => { trackActiveElementChange() }, { capture: true});

form.addEventListener("blur", () => { trackActiveElementChange() }, {capture: true});

```

Now, since the active element might be removed without a `blur` event, the same can be achieved with mutation observers:

```js

form.addEventListener("focus", () => { trackActiveElementChange() }, { capture: true});

new MutationObserver(entries => {

  if (Array.from(entries).some(entry => entry.removedNodes.length)
     trackActiveElementChange();
}).observe(form);

```

In essence the author can check that the node either lost focus or was removed, but you don't have an event that tells you that "either" happened.

So all the use cases can be covered, but of course there is a backwards compat risk as mentioned in this thread. We should make a decision on how to go forward as a balance between the backwards-compat risk and the other-browser-compat risk.

This is done as part of an effort to see if we can get rid of (as many as possible) scripts that can run in the middle of a DOM operation.

This one and events on iframe removal are the only ones remaining.

[Ian Kilpatrick]

To provide a little more context - activeElement tracking is used heavily by most webapp having non-trivial a11y implementations.

An example of this pattern is something like:

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

(From the first page of a github search of activeElement + setInterval).

(Above is for a Firefox specific extension I think - so doesn't have any if (FIREFOX) for the interval checking).

(Not this case exactly also - but same pattern).

setInterval checking is done for other browsers as there isn't a great way to check for activeElement changes (maybe there should be async events? - but thats a separate discussion).

But web developers might have only done the setInterval pattern for Firefox/Safari.

Ian

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJn%3DMYbiys600Gk5c%3DsW8B-iJOzRHqWq6Puc5nm8f-78zvxJvw%40mail.gmail.com.

[Yoav Weiss (@Shopify)]

Hmm, would it make sense then to work with the accessibility community to get them to move to mutation observers before attempting to remove here?

Do we know folks with contacts in these circles?

^^ +Aaron Leventhal 

[Aaron Leventhal]

A good start would be Scott O'Hara from Microsoft. He would know others to loop in.

[Noam Rosenthal]

On Tue, Apr 2, 2024 at 3:12 PM Aaron Leventhal <aleve...@google.com> wrote:

A good start would be Scott O'Hara from Microsoft. He would know others to loop in.

Thanks, will reach out. We see this deprecation as a long-haul thing, and sent this I2D to start the conversation. Thanks for the pointers!

[Noam Rosenthal]

Update on this: we're still interested in the next step but it's in the back burner until mutation event deprecation is complete, to avoid related noise.