Deprecation / Removal of Mutation Events

[mfreed7]

WebKittens

@annevk, @rniwa

Title of the spec

Mutation Events

URL to the spec

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

URL to the spec's repository

https://github.com/w3c/uievents

Issue Tracker URL

No response

Explainer URL

No response

TAG Design Review URL

No response

Mozilla standards-positions issue URL

mozilla/standards-positions#807

WebKit Bugzilla URL

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

Radar URL

No response

Description

I am going to make a push to remove Mutation Events from Chromium. This will not be easy, and success is definitely not guaranteed. The timeline is >= 1 year, if things go well. It's possible we might need to fall back to "delayed" mutation events that run at microtask or CEReactions timing. It's possible we might not be able to remove all of the events.

However, whatever happens, I'm hoping to get the support of WebKit (and Gecko), which will help convince developers who own existing usage to migrate to Mutation Observer. Some ideas, if you're supportive, might include:

1. Add or strengthen (as appropriate) the deprecation warnings in WebKit. I've already done this for Chromium, starting in M114.
2. Plan for a joint, coordinated removal from all browsers at some date/milestone in the future.
3. Write a co-authored blog post. I'm happy to drive this, but would love feedback, edits, and a WebKit-owned by-line.
4. Other suggestions appreciated.

[rniwa]

In my view, we've already paid the cost of mutation events. Since there are other events that fire at similar timing as mutation events such as blur / focus events and beforeunload / unload events, I'm somewhat skeptical of the benefit of removing these events. Having said that, I don't think we'd be necessarily opposed to trying to remove these events.

[mfreed7]

In my view, we've already paid the cost of mutation events. Since there are other events that fire at similar timing as mutation events such as blur / focus events and beforeunload / unload events, I'm somewhat skeptical of the benefit of removing these events. Having said that, I don't think we'd be necessarily opposed to trying to remove these events.

Ok, thanks for the reply. I'm a bit surprised - these events do get brought up often as the "blocker" for new things such as iframe reparenting. For sure they're not the only blocker, but they're usually the first one mentioned, and enough of a blocker to stop the conversation. They're also the only ones I've seen mentioned in a performance context.

Any way to get from "not necessarily opposed" to "supportive"?

[rniwa]

In my view, we've already paid the cost of mutation events. Since there are other events that fire at similar timing as mutation events such as blur / focus events and beforeunload / unload events, I'm somewhat skeptical of the benefit of removing these events. Having said that, I don't think we'd be necessarily opposed to trying to remove these events.

Ok, thanks for the reply. I'm a bit surprised - these events do get brought up often as the "blocker" for new things such as iframe reparenting.

I don't think mutation events are the reason reparenting iframe without reloading is hard.

For sure they're not the only blocker, but they're usually the first one mentioned, and enough of a blocker to stop the conversation. They're also the only ones I've seen mentioned in a performance context.

What are examples of features that are blocked by mutation events?

[mfreed7]

I don't think mutation events are the reason reparenting iframe without reloading is hard.

I agree they're not the only challenging thing about iframe reparenting, but they're often mentioned as being tricky in the discussion: whatwg/html#5484 (comment).

For sure they're not the only blocker, but they're usually the first one mentioned, and enough of a blocker to stop the conversation. They're also the only ones I've seen mentioned in a performance context.

What are examples of features that are blocked by mutation events?

I don't think any features are completely blocked by mutation events - we can always work around them. But that working around causes hassles, delays, and a loss of ergonomics. Some other examples (besides iframe reparenting) include:

• Sibling sorting
• DOM Parts
• this issue related to iframe events
• see the big list of other issues in the OP for #808

[annevk]

I think even if you manage to remove mutation events, the ordering issue for insertion and removal will continue to exist through elements with "synchronous" side effects, such as iframe and script.

[mfreed7]

I think even if you manage to remove mutation events, the ordering issue for insertion and removal will continue to exist through elements with "synchronous" side effects, such as iframe and script.

Yes, of course. As I mentioned above, mutation events are just one of a set of things blocking the addition of new things like moving iframes. But we'll have to tackle all of them to move forward, right?

The alternative to removing mutation events is specifying them, right? Is WebKit up for doing the work to do that? And aren't you fearful that standardizing mutation events will encourage more usage, and therefore more of the performance problems they create?

[annevk]

To answer your questions in order:

1. Agreed.
2. Chromium engineers at one point suggested delaying their dispatch (aligning them with mutation observers or custom element reactions) which could also be an alternative. Removing them outright would be nicer of course.
3. I can't say it's a priority, but I would be willing to help out of course.
4. Definitely.

[mfreed7]

2. Chromium engineers at one point suggested delaying their dispatch (aligning them with mutation observers or custom element reactions) which could also be an alternative. Removing them outright would be nicer of course.

Yes, Kent looked into this in 2019 and found that a not-insignificant number of sites would be broken by this change. E.g. they access the parent tree during DOMNodeRemoved. This breakage is obviously smaller than the breakage associated with removing DOMNodeRemoved completely, so yes this might be a fallback option.

3. I can't say it's a priority, but I would be willing to help out of course.
4. Definitely.

Given these two, and the fact that Chromium is the one offering to do the work to remove mutation events completely, could I ask again if WebKit is supportive of removal?

[annevk]

While we don't see much immediate benefit and compatibility requirements might require some of the relevant code to stay around for a long time, in the long term this could proof to be beneficial and lead to code simplification. As such, I suggest we endorse this deprecation attempt with "position: support" one week from now.