dom
dom copied to clipboard
whatwg
Define mutation events
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.
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.)
See also thread in https://lists.w3.org/Archives/Public/www-dom/2016JulSep/thread.html
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)
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 |
Latest here is https://lists.w3.org/Archives/Public/www-dom/2017JanMar/0004.html. So Blink still wants to change their behavior.
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.
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.
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.
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.
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.
I am not complaining as I saw this coming so I am just curious: while developers should stay away from long time deprecated features, I wonder why potentially huge breaking changes like this would ship when most people are on vacation or planning to ... if you were looking for causing troubles, you surely nailed the worst time after Xmas ... is there any rationale for picking this time around? 🤔
"just ordinary progress on things" would reason to me well too ... it's just that there are things and things to progress around specific time of the year (at least where I work we're always worried about shipping breaking changes when people are off) 😅
I am not complaining as I saw this coming so I am just curious: while developers should stay away from long time deprecated features, I wonder why potentially huge breaking changes like this would ship when most people are on vacation or planning to ... if you were looking for causing troubles, you surely nailed the worst time after Xmas ... is there any rationale for picking this time around? 🤔
I suppose a bit later in the year might have been slightly better. But my rationale was simply that I published a blog post announcing the removal in ~June of 2023, and I also added loud deprecation messages in Chrome around the same time. I wanted to give "plenty of time" for folks to see that messaging, so they weren't surprised. And "1 year" sounded like "plenty of time" without being so long that people dismissed it as too far into the future, so I chose June/July of 2024. I'm not sure there's ever a great time to do something like this, really. And again, I've so far been pleasantly surprised by the lack of major issues. Sorry if you ran into issues resulting from this removal!
Sorry if you ran into issues resulting from this removal!
don't be, the only project I have using those events is the deprecated document-register-element which is a polyfill for custom elements v0 and whoever is still using/needing that dead spec should expect issues sooner or later so it's all good.
That package has somehow still 77K weekly downloads so I assume some place will break but again, that's OK.
Worth mentioning this package was sponsored by Google AMP team too but I am sure they also moved away from it at some point in time, and the project also is abandoned.
That package has somehow still 77K weekly downloads so I assume some place will break but again, that's OK.
You could add a dependency to the mutation-events polyfill, perhaps? That might be enough to keep your polyfill operational.
I don’t want to maintain that project … it’s archived on GitHub and deprecated on npm
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?
Would folks be receptive to an HTML spec PR removing the ~17 mentions of "mutation events" at this point? And closing this bug?
https://github.com/whatwg/html/pull/10573 in case the answer is "yes".
With https://github.com/web-platform-tests/wpt/commit/e0c3477d2cff8aaaefd421ca6543198ec30dc3ef landed and MutationEvent already listed as historical in the standard I think this can indeed be closed. Congratulations! 🥳
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.cppwithout 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.
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.cppwithout 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?
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?
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?
https://github.com/w3c/uievents/pull/381
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.cppwithout 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 just wanted to check back in on this issue. Chromium has now successfully shipped the removal of the Mutation Events (deprecation) Origin Trial, in version 135, which went to stable Chrome this week. And I just landed the code to remove the enterprise policy also. At this point, the feature is disabled for all open web users of Chrome (and I believe Edge). So it should be safe to remove in other browsers now - please let me know if you run into any compat issues, since that would surprise me greatly.
https://github.com/w3c/uievents/pull/381 was merged, the reverse origin trial was removed. I don't see other unaddressed comments, so closing again.
Changes in other browsers:
- WebKit
- https://github.com/WebKit/WebKit/pull/39205
- https://github.com/WebKit/WebKit/pull/41650
- https://github.com/WebKit/WebKit/pull/44506
- Gecko
- https://bugzilla.mozilla.org/show_bug.cgi?id=1963043
filed an issue against caniuse, maybe someone here knows exact numbers: https://github.com/Fyrd/caniuse/issues/7336
