Get rid of mutation events
Categories
(Core :: DOM: Events, task, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox144 | --- | fixed |
People
(Reporter: ayg, Assigned: masayuki)
References
(Blocks 3 open bugs)
Details
(Keywords: dev-doc-complete, site-compat, webcompat:platform-bug)
Attachments
(14 files)
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review |
Updated•7 years ago
|
Updated•7 years ago
|
Updated•7 years ago
|
Updated•7 years ago
|
Updated•6 years ago
|
Updated•5 years ago
|
Updated•3 years ago
|
Updated•1 year ago
|
Comment 1•1 year ago
|
||
Per https://github.com/whatwg/dom/issues/305#issuecomment-2302407051 the rollout of removed mutation events is now 99% of Chrome users, though there's an origin trial to keep mutation events supported.
I think we can turn off mutation events in Nightly and also offer an origin trial to keep them supported. When the number of sites in Chrome's origin trial is very low or they remove the origin trial, we should be able to ship to release.
Updated•1 year ago
|
| Assignee | ||
Updated•1 year ago
|
Updated•10 months ago
|
Updated•10 months ago
|
| Assignee | ||
Comment 2•7 months ago
|
||
I think it's safe to delete the mutation events completely from our tree. Should I do that? Or do you have a patch for that?
Comment 3•7 months ago
|
||
I don't have a patch.
Looks like bug 1963043 landed to 140, which is the current ESR, so yes, I think we could remove the code.
| Assignee | ||
Comment 4•7 months ago
|
||
Thanks, then, I'll write a patch.
| Assignee | ||
Comment 5•7 months ago
|
||
Well, the patches are much much bigger than I've expected. So, I need more time to post the patches to get reviewed.
Unfortunately, my patches still have some mysterious timeout bugs in some tests.
https://treeherder.mozilla.org/jobs?repo=try&revision=31dd97e2c7b3b9427d97f1c3bd0d3a01d49af67f
| Assignee | ||
Comment 6•7 months ago
|
||
We won't keep supporting the legacy DOM mutation event listeners.
Therefore, it's impossible to keep collecting the data without making
new path to count the event listeners.
| Assignee | ||
Comment 7•7 months ago
|
||
MutationEvent_Bindings::MODIFICATION,
MutationEvent_Bindings::ADDITION and MutationEvent_Bindings::REMOVAL
will be removed. Therefore, we need alternative enum class for that.
This patch makes nsIFrame and subclasses use the new one.
| Assignee | ||
Comment 8•7 months ago
|
||
| Assignee | ||
Comment 9•7 months ago
|
||
It returns empty value when there is no mutation event listeners for
the performance. Therefore, after removing the mutation events, it
always return empty value. Therefore, we can make it return nothing.
Note that DevTools uses devtoolsattrmodified event [1], but it does
not have old attribute value, so, removing this code should not break
the DevTools' function.
| Assignee | ||
Comment 10•7 months ago
|
||
| Assignee | ||
Comment 11•7 months ago
|
||
It's unused.
| Assignee | ||
Comment 12•7 months ago
|
||
| Assignee | ||
Comment 13•7 months ago
|
||
| Assignee | ||
Comment 14•7 months ago
|
||
| Assignee | ||
Comment 15•7 months ago
|
||
| Assignee | ||
Comment 16•7 months ago
|
||
| Assignee | ||
Comment 17•7 months ago
|
||
Unfortunately, we need to keep dispatching devtoolschildremoved event
to the DevTools. Therefore, this patch renames the DOMNodeRemoved
event dispatcher and related methods.
| Assignee | ||
Comment 18•7 months ago
|
||
| Assignee | ||
Comment 19•7 months ago
|
||
Comment 20•7 months ago
|
||
Hi Masayuki,
I had a quick look at the stack, and this patch removes most of the mutation events available in DevTools as event breakpoints. But I realize they're already broken in Nightly, at least I can't seem to trigger them. I tried to force dom.mutation_events.enabled back to true, I also checked back against ESR 128, but I still can't get the feature to work.
So it feels like this stack is only removing an already broken / missing feature from DevTools, but before we review the patch, do you know why / for how long this has been completely broken in DevTools?
| Assignee | ||
Comment 21•7 months ago
|
||
Hmm, I couldn't reach how to notify DevTools of an event dispatching. Do you know where does it? So, I don't know how to implement the feature and I have no idea how to break it.
Comment 22•7 months ago
|
||
(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #21)
Hmm, I couldn't reach how to notify DevTools of an event dispatching. Do you know where does it? So, I don't know how to implement the feature and I have no idea how to break it.
The main way all DOM Events are trigerring breakpoints in DevTools is via this line:
https://searchfox.org/firefox-main/rev/e02959386f6f89c1476edba10b3902f4e4f3ed4c/dom/events/EventListenerManager.cpp#1377
Maybe<EventCallbackDebuggerNotificationGuard> dbgGuard;
This will ultimately inform DevTools codebase that a DOM event is being processed and pause accordingly.
But may be the Mutation events were going through a special codepath ?
Or DevTools codebase was poorly identifying them.
| Assignee | ||
Comment 23•7 months ago
|
||
Thanks, but as far as I've tested, at least, DOMNodeInserted, DOMNodeRemvoed and DOMCharacterDataModified break points work for me.
I tested within my test suite, enable the pref and choose these events to log them from "Chose event types to log...".
I guess you took mistake to listen to the DOM mutation events when you tested?
Comment 24•7 months ago
|
||
Oh yes for some reason I thought this would break on whatever would trigger the mutation, but you are right. For the breakpoints to trigger we have to actually listen to the events in the content page. So if we're removing the events on the platform side it's completely fine to remove the DevTools counterpart.
And thanks for sharing your test page, looks really useful!
| Assignee | ||
Comment 25•7 months ago
|
||
Robert Longson: Could you review attachment 9510242 [details]? Thanks.
Updated•7 months ago
|
Comment 26•7 months ago
|
||
| Assignee | ||
Comment 27•7 months ago
|
||
Waiting for a day to file follow up bugs to link to the relevant inline comment in searchfox.
Comment 28•7 months ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/f2f10ce158d7
https://hg.mozilla.org/mozilla-central/rev/a915e9f37b7a
https://hg.mozilla.org/mozilla-central/rev/f890e764bf2c
https://hg.mozilla.org/mozilla-central/rev/fbdefc1feb4a
https://hg.mozilla.org/mozilla-central/rev/3660b1202a99
https://hg.mozilla.org/mozilla-central/rev/73507f256e68
https://hg.mozilla.org/mozilla-central/rev/47b14ec37605
https://hg.mozilla.org/mozilla-central/rev/c5c00572442e
https://hg.mozilla.org/mozilla-central/rev/c4d54190394d
https://hg.mozilla.org/mozilla-central/rev/2d3ab07233d8
https://hg.mozilla.org/mozilla-central/rev/c428e8523089
https://hg.mozilla.org/mozilla-central/rev/6e2db8483078
https://hg.mozilla.org/mozilla-central/rev/81e10ab76e1d
https://hg.mozilla.org/mozilla-central/rev/18540c9751b2
Updated•7 months ago
|
Comment 29•7 months ago
|
||
FF144 MDN docs work for this can be tracked in https://github.com/mdn/content/issues/41137
Looking at https://developer.mozilla.org/en-US/docs/Web/API/MutationEvent the events are marked as removed in FF140. My assumption is that the events were disabled behind dom.mutation_events.enabled in that version, and this version actually removes all the code. Is that correct?
If so, there is nothing to do for this from the MDN perspective.
Updated•7 months ago
|
| Assignee | ||
Comment 30•7 months ago
|
||
Right, and yes, you don't need to update MDN for this.
Updated•6 months ago
|
Description
•