Define mutation events

[annevk]

Telemetry from Firefox release builds: 39 0.4% of window/node objects had seen mutation event listener somewhere in them, 47 0.22%.

Chrome:

• DOMCharacterDataModified: https://www.chromestatus.com/metrics/feature/timeline/popularity/148 0.016%
• DOMNodeInserted: https://www.chromestatus.com/metrics/feature/timeline/popularity/144 0.6%
• DOMNodeInsertedIntoDocument: https://www.chromestatus.com/metrics/feature/timeline/popularity/147 0.007%
• DOMNodeRemoved: https://www.chromestatus.com/metrics/feature/timeline/popularity/145 0.077%
• DOMNodeRemovedFromDocument: https://www.chromestatus.com/metrics/feature/timeline/popularity/146 0.021%
• DOMSubtreeModified: https://www.chromestatus.com/metrics/feature/timeline/popularity/143 0.4%

Chrome probably inherits non-support for DOMAttrModified from WebKit: https://bugs.webkit.org/show_bug.cgi?id=8191 (WONTFIX, \o/).

A couple of the Chrome numbers are below the Blink threshold of 0.03%.

@esprehn has mentioned he wanted to change how these events are dispatched in Chrome to offset some of their negative side effects. Is this happening?

According to https://msdn.microsoft.com/en-us/library/dn265032.aspx Internet Explorer does not support *IntoDocument and *FromDocument, but does support DOMAttrModified.

It seems like DOM Standard needs to define

• DOMNodeInserted
• DOMNodeRemoved
• DOMSubtreeModified

at a minimum. "Asynchronous timing" would be great, but we should only specify that if Chrome manages to ship it.

[smaug----]

I'm still hoping we actually try to get rid of mutation events.
Isn't Firefox still the only browser warn about their use.

(FYI, Firefox telemetry compares Window objects, in which a listener for mutation events was added to either Window or to some Node, to those Window objects where such listeners weren't added.)

[foolip]

See also thread in https://lists.w3.org/Archives/Public/www-dom/2016JulSep/thread.html

[zcorpan]

20 most commonly used scripts in httparchive that use the strings above (if somebody wants to analyze feasibility of changing timings or so):

Row	url	num
1	https://s.ytimg.com/yts/jsbin/player-en_US-vflHuW2fm/base.js	16661
2	https://s.ytimg.com/yts/jsbin/player-en_US-vfld7sVQ3/base.js	7987
3	https://s.ytimg.com/yts/jsbin/player-en_US-vflua32tg/base.js	3397
4	https://s.ytimg.com/yts/jsbin/player-en_US-vflI2is8G/base.js	1448
5	https://tags.crwdcntrl.net/c/9234/cc.js?ns=_cc9234	1261
6	http://imasdk.googleapis.com/js/sdkloader/ima3.js	1221
7	https://secure.flashtalking.com/frameworks/js/api/2/9/html5API.js	756
8	http://tags.crwdcntrl.net/c/9193/cc.js?ns=_cc9193	726
9	http://s0.2mdn.net/instream/html5/ima3.js	685
10	http://prscripts.com/pub.js	633
11	https://www.fullstory.com/s/fs.js	429
12	http://imasdk.googleapis.com/js/core/bridge3.138.5_en.html	394
13	http://tags.crwdcntrl.net/c/8060/cc_af.js	333
14	http://tags.crwdcntrl.net/c/4575/cc_af.js	327
15	http://st.chatango.com/h5/gz/r0802161130/id.html	320
16	http://imasdk.googleapis.com/js/core/bridge3.137.0_en.html	318
17	https://secure.flashtalking.com/frameworks/js/api/2/8/html5API.js	313
18	https://choices.truste.com/ca?pid=ehi01&aid=moosylvania01&cid=0413&c=moosylvania01cont2&w=300&h=250&admarker=dynamic	304
19	https://choices.truste.com/ca?aid=tradedesk01&pid=tradedesk01&cid=10312015&w=728&h=90&c=tradedesk01cont1&js=pmw2	289
20	http://st.chatango.com/h5/gz/r0805161606/id.html	280

Query was

SELECT * FROM (
  SELECT page, url, REGEXP_EXTRACT(body, r'["\'](DOM(?:CharacterDataModified|Node(?:Inserted|Removed)(?:(?:Into|From)Document)?|SubtreeModified))["\']') AS ev
  FROM [httparchive:har.2016_08_01_chrome_requests_bodies]
) WHERE ev != "null"
ORDER BY ev

(result of this 88,540 rows, csv is 10.8MB, at https://gist.github.com/zcorpan/6e16e387cfc6cdf377944c7960a02884 )

SELECT url, COUNT(page) AS num FROM [test.mutation_events_2016_08_01] 
GROUP BY url
ORDER BY num DESC
LIMIT 20

(result above)

[zcorpan]

Usage of each event

SELECT ev, COUNT(page) AS num FROM [test.mutation_events_2016_08_01] 
GROUP BY ev
ORDER BY num DESC

Row	ev	num
1	DOMSubtreeModified	40083
2	DOMNodeInserted	35337
3	DOMNodeRemoved	7211
4	DOMCharacterDataModified	5549
5	DOMNodeRemovedFromDocument	329
6	DOMNodeInsertedIntoDocument	30

[annevk]

Latest here is https://lists.w3.org/Archives/Public/www-dom/2017JanMar/0004.html. So Blink still wants to change their behavior.

[annevk]

Once we define these (it seems ever more unlikely we'll be able to remove them), we'll need to make sure to not fire them inside shadow trees. Tracked by https://bugzilla.mozilla.org/show_bug.cgi?id=1489858 for Fx.

[domenic]

Noting for the record that when/if we fix this, we'd need to update HTML (https://www.w3.org/Bugs/Public/show_bug.cgi?id=23036) and UI Events. UI Events currently has a decent amount of spec text around mutation events.

[tkent-google]

Elliot proposed dispatching DOM mutation events on CEReactions timing in 2016. I investigated the feasibility of the proposal.

TL;DR: Not feasible for DOMNodeRemoved, feasible for DOMNodeRemovedFromDocument but it won't have much benefit, and feasible for other events.

The details.

[dbaron]

It's worth noting that the removal of mutation events has shipped in Chrome 127 thanks to @mfreed7. While there is an enterprise policy that we expect to support for at least 9 months (and there have been a bunch of bugs that ended with telling folks that they need to use the enterprise policy to keep their apps working until those apps can be fixed), the removal seems so far to be sticking.

[mfreed7]

It's worth noting that the removal of mutation events has shipped in Chrome 127 thanks to @mfreed7. While there is an enterprise policy that we expect to support for at least 9 months (and there have been a bunch of bugs that ended with telling folks that they need to use the enterprise policy to keep their apps working until those apps can be fixed), the removal seems so far to be sticking.

Knock on wood! 😄 But yeah, so far the removal is going cautiously well. It only very recently (last 48 hours) reached 100% of stable users, and it sometimes takes a few days for bugs to trickle back to me. I'll try to check back in here after a few more weeks with a more definitive status update. But assuming that's successful, I'd strongly advocate for this issue being closed as "WontFix". There are also a few mentions of mutation events in the spec (e.g. https://html.spec.whatwg.org/#concept-document-fire-mutation-events-flag) that should likely be deleted.

[mfreed7]

Knock on wood! 😄 But yeah, so far the removal is going cautiously well. It only very recently (last 48 hours) reached 100% of stable users, and it sometimes takes a few days for bugs to trickle back to me. I'll try to check back in here after a few more weeks with a more definitive status update. But assuming that's successful, I'd strongly advocate for this issue being closed as "WontFix". There are also a few mentions of mutation events in the spec (e.g. https://html.spec.whatwg.org/#concept-document-fire-mutation-events-flag) that should likely be deleted.

Alright, I think I'm cautiously ready to come back here and announce victory over mutation events. They have been disabled for 99% of Chrome users (for desktop and mobile, and about 10% and rising for webview) since July 23. There have been a few affected folks, but mostly they seem to have been able to migrate off of mutation events fairly easily. (Usage of my polyfill has jumped significantly.) There is still work to do, in that there are many people that requested origin trials, and those folks will need more time to migrate. But I believe the feature can now be removed from the open web.

Would folks be receptive to an HTML spec PR removing the ~17 mentions of "mutation events" at this point? And closing this bug?

[mfreed7]

Would folks be receptive to an HTML spec PR removing the ~17 mentions of "mutation events" at this point? And closing this bug?

whatwg/html#10573 in case the answer is "yes".

[annevk]

With web-platform-tests/wpt@e0c3477 landed and MutationEvent already listed as historical in the standard I think this can indeed be closed. Congratulations! 🥳

[annevk]

I have a couple of concerns given the existence of the "reverse origin trial":

• It's not transparent which websites continue to be able to use mutation events in Chromium. This makes it much harder for other browsers to remove mutation events before May 2025. E.g., while WebKit in theory could lean on Quirks.cpp without knowledge of what to fill it with it'd turn into a game of whack-a-mole. Also, Chromium has extended those deprecation deadlines in the past (e.g., with locking SharedArrayBuffer behind COOP+COEP, that might still be ongoing?).
• Meanwhile Chromium passes the relevant WPT tests as WPT is not registered for the various reverse origin trials. And other browsers might get blame for not passing them as casual onlookers won't be aware of the various mechanisms in place.

I don't really have a good idea of how to handle this, but I'm going to reopen this for now to keep track of this.

[mfreed7]

I have a couple of concerns given the existence of the "reverse origin trial":

• It's not transparent which websites continue to be able to use mutation events in Chromium. This makes it much harder for other browsers to remove mutation events before May 2025. E.g., while WebKit in theory could lean on Quirks.cpp without knowledge of what to fill it with it'd turn into a game of whack-a-mole. Also, Chromium has extended those deprecation deadlines in the past (e.g., with locking SharedArrayBuffer behind COOP+COEP, that might still be ongoing?).

This is a very good point. There are some sites using the origin trial, though not a ton. But I agree it might be the best to simply wait for the end of the OT before turning off mutation events in other browsers, to be safe.

I've been very actively trying to manage the usage of mutation events coming up to this removal, and I'll continue to do that afterwards for the origin trial registrants. E.g. I'll be sending reminder emails to all registrants that the OT is coming to a close, and warning that we won't be extending it for anything other than very dire circumstances. But you're right that there's a chance we need to extend the deadline.

Perhaps for now, the answer is "do nothing", and I'll check back in here toward the first quarter of Q1 with an update?

[domenic]

I merged the HTML PR, but reopening per the latest comment.

It also occurred to me that we should remove https://w3c.github.io/uievents/#legacy-mutationevent-events and other mentions of MutationEvent in that spec. @mfreed7 up for that too?

[mfreed7]

I merged the HTML PR, but reopening per the latest comment.

Thanks!

It also occurred to me that we should remove https://w3c.github.io/uievents/#legacy-mutationevent-events and other mentions of MutationEvent in that spec. @mfreed7 up for that too?

w3c/uievents#381