Request for Deprecation Trial: Deprecate Mutation Events

[Mason Freed]

Contact emails

mas...@chromium.org

Explainer

None

Specification

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

Summary

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. Mutation events are deprecated starting in Chrome 115, and support will be disabled by default starting in Chrome 127, around July 30, 2024. A Deprecation Trial will be available starting in Chrome 124, and extending through Chrome 134, which can be used to extend the time a site has to migrate by ~9 months, until March 25, 2025.

Blink component

Blink>DOM

Search tags

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

TAG review

None

TAG review status

Not applicable

Chromium Trial Name

MutationEvents

Origin Trial documentation link

https://developer.chrome.com/blog/mutation-events-deprecation

WebFeature UseCounter name

kDOMNodeRemovedEvent

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 DOMNodeInsertedIntoDocument and DOMNodeRemovedFromDocument events are not fired by Gecko. That, plus the low use counters for those two plus DOMCharacterDataModified, mean that these 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. This npm package attempts to polyfill Mutation Events using Mutation Observer: https://www.npmjs.com/package/mutation-events.

Gecko: Positive (https://github.com/mozilla/standards-positions/issues/807) "very strong positive position"

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/192)

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

Goals for experimentation

Ongoing technical constraints

Debuggability

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

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

No

Flag name on chrome://flags

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1446498

Estimated milestones

Shipping on desktop	115
OriginTrial desktop last	134
OriginTrial desktop first	124

Shipping on Android	115
OriginTrial Android last	134
OriginTrial Android first	124

Shipping on WebView	115
OriginTrial webView last	134
OriginTrial webView first	124

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5083947249172480

Links to previous Intent discussions

Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/qDsKRU-cQ_4/m/isA1mZ_aAAAJ

This intent message was generated by Chrome Platform Status.

[Vladimir Levin]

This is very exciting! Thank you for working on this.

Do you know whether the existing usage is feature checked? 1.58% seems very high, but if it's feature checked and fallback is something like mutation observer, then it would be a lot more safe imho. Also, do you have a sense of where the usage is coming from (a few large frameworks vs a ton of smaller sites)? The npm package you listed, for example, would use the actual events if available, so sites using that polyfill would also count towards the event usage if the browser supports those even though that's "safe", right?

--
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%3DNeDjevtANjMn1NUK83UGyJyv4HrLCFkjs9fhL6UVov_uAkA%40mail.gmail.com.

[Mason Freed]

On Thu, Feb 1, 2024 at 7:12 AM Vladimir Levin <vmp...@google.com> wrote:

This is very exciting! Thank you for working on this.

Thanks!

 

Do you know whether the existing usage is feature checked? 1.58% seems very high, but if it's feature checked and fallback is something like mutation observer, then it would be a lot more safe imho. Also, do you have a sense of where the usage is coming from (a few large frameworks vs a ton of smaller sites)?

Unfortunately, I haven't seen a lot of feature checking around mutation events directly. I have definitely seen feature checks on MutationObserver that then avoids trying to use mutation events. But obviously those aren't part of the use counter data, since they don't attach mutation event listeners.

I've been looking into UKM data to see if I can suss out any large usage patterns. I've found a few, e.g. QuillJS, which contribute a significant chunk of usage to many sites. Thankfully in the cases I've seen, the (large) deprecation warnings I've added to Chrome seem to be doing their thing.  My hope is that direct outreach (which I've done in a few cases), heavy warnings, and eventually the start of the removal effort (plus this OT to give sites an extension) will nudge the remaining users to migrate.

 

 The npm package you listed, for example, would use the actual events if available, so sites using that polyfill would also count towards the event usage if the browser supports those even though that's "safe", right?

This is an excellent point that I hadn't thought of. I'm going to modify the polyfill right now to *always* run. That way polyfilled usage will no longer be counted. I'm used to writing polyfills for features that are getting *added*, where you want to avoid using the polyfill when the feature is supported. This is the opposite.

Thanks,

Mason

[Vladimir Levin]

On Thu, Feb 1, 2024 at 6:30 PM Mason Freed <mas...@chromium.org> wrote:

On Thu, Feb 1, 2024 at 7:12 AM Vladimir Levin <vmp...@google.com> wrote:

This is very exciting! Thank you for working on this.

Thanks!

 

Do you know whether the existing usage is feature checked? 1.58% seems very high, but if it's feature checked and fallback is something like mutation observer, then it would be a lot more safe imho. Also, do you have a sense of where the usage is coming from (a few large frameworks vs a ton of smaller sites)?

Unfortunately, I haven't seen a lot of feature checking around mutation events directly. I have definitely seen feature checks on MutationObserver that then avoids trying to use mutation events. But obviously those aren't part of the use counter data, since they don't attach mutation event listeners.

I've been looking into UKM data to see if I can suss out any large usage patterns. I've found a few, e.g. QuillJS, which contribute a significant chunk of usage to many sites. Thankfully in the cases I've seen, the (large) deprecation warnings I've added to Chrome seem to be doing their thing.  My hope is that direct outreach (which I've done in a few cases), heavy warnings, and eventually the start of the removal effort (plus this OT to give sites an extension) will nudge the remaining users to migrate.

It's good to know that QuillJS seems to be addressing their issue in 2.0, although the currently published stable version is still 1.x. I just wanted to verify the timeline for disabling these features. The trial is for 124-134 and the feature will be turned off by default in 127. Sounds reasonable to me, but I'd encourage checking whether QuillJS ships to 2.0 in the 127 timeframe :)

[Mason Freed]

On Fri, Feb 2, 2024 at 9:37 AM Vladimir Levin <vmp...@google.com> wrote:

It's good to know that QuillJS seems to be addressing their issue in 2.0, although the currently published stable version is still 1.x. I just wanted to verify the timeline for disabling these features. The trial is for 124-134 and the feature will be turned off by default in 127. Sounds reasonable to me, but I'd encourage checking whether QuillJS ships to 2.0 in the 127 timeframe :)

I 100% agree. I have been trying to follow up with that team to see what the timeline looks like. But more importantly, I did my own testing and I can't see any negative effects on QuillJS pre-2.0 with Mutation Events disabled. So my hope is that even if the timeline doesn't line up, things might be "ok".

That's another important thing: I've been running locally with Mutation Events disabled completely for about 4 months now, and I have yet to notice anything broken. That's anecdotal, but makes me feel a bit better that perhaps even if there is usage on a site, it might not be critical or noticable.

Thanks,

Mason

[Yoav Weiss (@Shopify)]

On Fri, Feb 2, 2024 at 7:37 PM Mason Freed <mas...@chromium.org> wrote:

On Fri, Feb 2, 2024 at 9:37 AM Vladimir Levin <vmp...@google.com> wrote:

It's good to know that QuillJS seems to be addressing their issue in 2.0, although the currently published stable version is still 1.x. I just wanted to verify the timeline for disabling these features. The trial is for 124-134 and the feature will be turned off by default in 127. Sounds reasonable to me, but I'd encourage checking whether QuillJS ships to 2.0 in the 127 timeframe :)

I 100% agree. I have been trying to follow up with that team to see what the timeline looks like. But more importantly, I did my own testing and I can't see any negative effects on QuillJS pre-2.0 with Mutation Events disabled. So my hope is that even if the timeline doesn't line up, things might be "ok".

Note that them shipping 2.0 and everyone upgrading to 2.0 are not the same thing, and is unlikely to happen at the same time..

 

That's another important thing: I've been running locally with Mutation Events disabled completely for about 4 months now, and I have yet to notice anything broken. That's anecdotal, but makes me feel a bit better that perhaps even if there is usage on a site, it might not be critical or noticable.

What would breakage look like? Are we expecting JS to be borked entirely? Or do we expect the events to stop firing, resulting in hopefully smaller and less-visible breakage?

 

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

[Mason Freed]

On Tue, Feb 6, 2024 at 3:38 AM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

Note that them shipping 2.0 and everyone upgrading to 2.0 are not the same thing, and is unlikely to happen at the same time..

Agreed for sure. That’s why I’ve been trying to get them to confirm exactly what functionality will be broken. I can’t see any breakage myself.

What would breakage look like? Are we expecting JS to be borked entirely? Or do we expect the events to stop firing, resulting in hopefully smaller and less-visible breakage?

No there shouldn’t be any exceptions thrown, so the JS should be fine. It’s just that those events will not be fired. The breakage, whatever it is, is so small that I’ve yet been able to notice it. That’s not to say there isn’t risk - there surely is. Just that I’m hopeful.

[Yoav Weiss (@Shopify)]

Just to clarify - this intent is asking to start a deprecation trial for mutation events in 124 and ending it in 134, but you'd send a separate intent on the actual removal of mutation events?

[Mason Freed]

On Wed, Feb 7, 2024 at 6:06 AM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

Just to clarify - this intent is asking to start a deprecation trial for mutation events in 124 and ending it in 134, but you'd send a separate intent on the actual removal of mutation events?

Yes, that’s correct. Here’s the request for deprecation thread:

https://groups.google.com/a/chromium.org/g/blink-dev/c/qDsKRU-cQ_4/m/P_iXWapTBgAJ

And I’ll send a request for removal closer to 126.

Thanks,

Mason

[Yoav Weiss (@Shopify)]

LGTM to run a deprecation trial M124-M134 inclusive.

May our mutations no longer be eventful!!

[Mason Freed]

On Wed, Feb 7, 2024 at 6:52 AM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

LGTM to run a deprecation trial M124-M134 inclusive.

Thanks!

[Daniel Bratell]

Just thinking about possible use cases for mutation events, do you know what the browser extension situation is? Those might have legitimate reason to react to page changes and maybe some of them use the old events?

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDh1kCKirZo_qYm%2B2FZEXJYn8P3BY%2B7zLbAWMLGx-BRKTA%40mail.gmail.com.

[Mason Freed]

On Sat, Feb 10, 2024 at 5:39 AM Daniel Bratell <brat...@gmail.com> wrote:

Just thinking about possible use cases for mutation events, do you know what the browser extension situation is? Those might have legitimate reason to react to page changes and maybe some of them use the old events?

That's a good question, and I don't have a great answer. Except perhaps to say that I would hope MutationObserver should be able to handle any such reactions in the same way that an open web site would. Do you have a reason to think extensions specifically need synchronous events for mutations?

Thanks,

Mason

[Daniel Bratell]

On 2024-02-17 03:22, Mason Freed wrote:

On Sat, Feb 10, 2024 at 5:39 AM Daniel Bratell <brat...@gmail.com> wrote:

Just thinking about possible use cases for mutation events, do you know what the browser extension situation is? Those might have legitimate reason to react to page changes and maybe some of them use the old events?

That's a good question, and I don't have a great answer. Except perhaps to say that I would hope MutationObserver should be able to handle any such reactions in the same way that an open web site would. Do you have a reason to think extensions specifically need synchronous events for mutations?

No, not at all. Just covering all the bases.

I assume injected extension scripts would show up in use counter data too, so if there are such extensions, they are unlikely to be one of the more popular ones.