Intent to Deprecate: Mutation Events

[Mason Freed]

Contact emails

mas...@chromium.org

Explainer

None

Specification

https://w3c.github.io/uievents/#legacy-event-types

Summary

Synchronous Mutation Events, including `DOMSubtreeModified`, `DOMNodeInserted`, `DOMNodeRemoved`, `DOMNodeRemovedFromDocument`, `DOMNodeInsertedIntoDocument`, and `DOMCharacterDataModified`, are quite bad for page performance, and also significantly increase the complexity of adding new features to the Web. These APIs were deprecated from the spec (https://w3c.github.io/uievents/#legacy-event-types) in 2011, and were replaced (in 2012) by the much better-behaved Mutation Observer API. Usage of the obsolete Mutation Events must be migrated to Mutation Observer.

Blink component

Blink>DOM

Motivation

Mutation Events have been deprecated for over a decade, with the replacement (Mutation Observer) available also for over a decade. The fact that these events are still supported in browsers makes the addition of new features much more difficult, prohibitively so in some cases. For example, these feature requests and projects are all negatively impacted by the existence of Mutation Events: - iFrame reparenting: https://github.com/whatwg/html/issues/5484 and https://github.com/whatwg/dom/issues/891 - Child reordering: https://github.com/whatwg/dom/issues/586 - DOM Parts and batch DOM updates: https://github.com/WICG/webcomponents/blob/gh-pages/proposals/DOM-Parts.md Given that the feature has been spec-deprecated for a decade, it makes sense to officially deprecate these APIs in Chrome, and work toward removing them.

Initial public proposal

None

Search tags

MutationEvent, DOMSubtreeModified, DOMNodeInserted, DOMNodeRemoved, DOMNodeRemovedFromDocument, DOMNodeInsertedIntoDocument, DOMCharacterDataModified

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

There are technically 9 Mutation Events, but Chromium only implements 6 of them. Their use counters vary significantly: - DOMNodeInsertedIntoDocument: 0.006% - DOMNodeRemovedFromDocument: 0.012% - DOMCharacterDataModified: 0.016% - DOMNodeRemoved: 0.77% - DOMSubtreeModified: 0.81% - DOMNodeInserted: 1.58% The first three could likely be fairly easily removed after some time. The last three have quite significant usage, and more study and outreach will be required to bring this usage down below safe removal limits, which will take significant time. Tentatively, we're aiming for M126 as the last version of Chrome that supports the events above, ending July 30, 2024.

Gecko: No signal (https://github.com/whatwg/dom/issues/305#issuecomment-241686139) Old comments indicate support, but no official position yet.

WebKit: No signal

Web developers: No signals

Other signals:

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

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

No

Flag name

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1446498

Estimated milestones

Shipping on desktop

127

Shipping on Android

127

Shipping on WebView

127

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5083947249172480

Links to previous Intent discussions

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

Thanks for taking that on!!

On Thu, May 18, 2023 at 9:29 PM Mason Freed <mas...@chromium.org> wrote:

Contact emails

mas...@chromium.org

Explainer

None

Specification

https://w3c.github.io/uievents/#legacy-event-types

Summary

Synchronous Mutation Events, including `DOMSubtreeModified`, `DOMNodeInserted`, `DOMNodeRemoved`, `DOMNodeRemovedFromDocument`, `DOMNodeInsertedIntoDocument`, and `DOMCharacterDataModified`, are quite bad for page performance, and also significantly increase the complexity of adding new features to the Web. These APIs were deprecated from the spec (https://w3c.github.io/uievents/#legacy-event-types) in 2011, and were replaced (in 2012) by the much better-behaved Mutation Observer API. Usage of the obsolete Mutation Events must be migrated to Mutation Observer.

Blink component

Blink>DOM

Motivation

Mutation Events have been deprecated for over a decade, with the replacement (Mutation Observer) available also for over a decade. The fact that these events are still supported in browsers makes the addition of new features much more difficult, prohibitively so in some cases. For example, these feature requests and projects are all negatively impacted by the existence of Mutation Events: - iFrame reparenting: https://github.com/whatwg/html/issues/5484 and https://github.com/whatwg/dom/issues/891 - Child reordering: https://github.com/whatwg/dom/issues/586 - DOM Parts and batch DOM updates: https://github.com/WICG/webcomponents/blob/gh-pages/proposals/DOM-Parts.md Given that the feature has been spec-deprecated for a decade, it makes sense to officially deprecate these APIs in Chrome, and work toward removing them.

Was the impact due to the supporting these events in the code or due to the fact that we needed to actually run them?

If we'd have to run a long deprecation trial, would that still negatively impact the platform's evolution?

 

Initial public proposal

None

Search tags

MutationEvent, DOMSubtreeModified, DOMNodeInserted, DOMNodeRemoved, DOMNodeRemovedFromDocument, DOMNodeInsertedIntoDocument, DOMCharacterDataModified

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

There are technically 9 Mutation Events, but Chromium only implements 6 of them. Their use counters vary significantly: - DOMNodeInsertedIntoDocument: 0.006% - DOMNodeRemovedFromDocument: 0.012% - DOMCharacterDataModified: 0.016% - DOMNodeRemoved: 0.77% - DOMSubtreeModified: 0.81% - DOMNodeInserted: 1.58% The first three could likely be fairly easily removed after some time. The last three have quite significant usage, and more study and outreach will be required to bring this usage down below safe removal limits, which will take significant time.

Turning those use counters into UKM can be interesting.

 

Tentatively, we're aiming for M126 as the last version of Chrome that supports the events above, ending July 30, 2024.

Are you planning to remove all of them at the same time, despite the order of magnitude difference in usage?

 

Gecko: No signal (https://github.com/whatwg/dom/issues/305#issuecomment-241686139) Old comments indicate support, but no official position yet.

WebKit: No signal

Can we file for positions? A joint effort could help here.

 

Web developers: No signals

Other signals:

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

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

No

Flag name

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1446498

Estimated milestones

Shipping on desktop

127

Shipping on Android

127

Shipping on WebView

127

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5083947249172480

Links to previous Intent discussions

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/CAM%3DNeDgP1mWEoDABHmKfCXSSFO9ZyQDQ5p7h_TtN51ZnyvxSSg%40mail.gmail.com.

[Mason Freed]

On Tue, May 23, 2023 at 3:46 AM Yoav Weiss <yoav...@chromium.org> wrote:

Thanks for taking that on!!

I may regret it, but thanks.

 

On Thu, May 18, 2023 at 9:29 PM Mason Freed <mas...@chromium.org> wrote:

Motivation

Mutation Events have been deprecated for over a decade, with the replacement (Mutation Observer) available also for over a decade. The fact that these events are still supported in browsers makes the addition of new features much more difficult, prohibitively so in some cases. For example, these feature requests and projects are all negatively impacted by the existence of Mutation Events: - iFrame reparenting: https://github.com/whatwg/html/issues/5484 and https://github.com/whatwg/dom/issues/891 - Child reordering: https://github.com/whatwg/dom/issues/586 - DOM Parts and batch DOM updates: https://github.com/WICG/webcomponents/blob/gh-pages/proposals/DOM-Parts.md Given that the feature has been spec-deprecated for a decade, it makes sense to officially deprecate these APIs in Chrome, and work toward removing them.

Was the impact due to the supporting these events in the code or due to the fact that we needed to actually run them?

If we'd have to run a long deprecation trial, would that still negatively impact the platform's evolution? 

Some of both, I suppose. Supporting Mutation Events means that engineers *always* have to think about what might happen when a mutation is made, and it's easy to overlook that and create a bug. If no listeners are added by the page, then there's not much performance penalty, so actually running them only penalizes sites that use them. But these events are always hanging over new API additions, such as iframe reparenting and DOM Parts.

It'd obviously be better to get this over quickly, but that'll be very hard. Indeed it might prove impossible. These events will continue to negatively impact the platform's evolution until we get rid of them.

Interoperability and Compatibility

There are technically 9 Mutation Events, but Chromium only implements 6 of them. Their use counters vary significantly: - DOMNodeInsertedIntoDocument: 0.006% - DOMNodeRemovedFromDocument: 0.012% - DOMCharacterDataModified: 0.016% - DOMNodeRemoved: 0.77% - DOMSubtreeModified: 0.81% - DOMNodeInserted: 1.58% The first three could likely be fairly easily removed after some time. The last three have quite significant usage, and more study and outreach will be required to bring this usage down below safe removal limits, which will take significant time.

Turning those use counters into UKM can be interesting. 

Definitely! That's on my to-do list. 

 

Tentatively, we're aiming for M126 as the last version of Chrome that supports the events above, ending July 30, 2024.

Are you planning to remove all of them at the same time, despite the order of magnitude difference in usage? 

 

I'm playing that question by ear. My guess would be that we will be able to remove DOMNodeInsertedIntoDocument, DOMNodeRemovedFromDocument, and DOMCharacterDataModified more quickly than the other three. If their usage falls low enough at some point, I'll come back here for approval to remove them sooner.

Gecko: No signal (https://github.com/whatwg/dom/issues/305#issuecomment-241686139) Old comments indicate support, but no official position yet.

WebKit: No signal

Can we file for positions? A joint effort could help here. 

Yep! Here are Mozilla and WebKit position requests. I'm hoping they'll be supportive and perhaps we can jointly remove the APIs, or at least work together. 

Other suggestions would always be appreciated.

Thanks,

Mason

[Mason Freed]

Quick update and PSA on this deprecation thread. The update is that usage seems to be dropping fairly rapidly, which is good. I've also been able to turn off mutation events for all of Google's internal web tests, and experienced very few failures in that process. Both are good signs.

The PSA is that I'm planning to disable mutation events on Canary/Dev/Beta of Chrome for 50-100% of users, starting in M124. I'll use that as an early indication of problems, carefully watching for reported bugs. I have created a bug template for that purpose.

Questions or concerns: please let me know.

Thanks,

Mason

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.