Intent to Ship: Deprecate Mutation Events

I recall that some of this usage was feature detected: if mutation events are supported, use them; otherwise, use something else. Unfortunately, that makes it difficult to estimate the expected number of breakages. I agree though that it would be nice to understand the type of usage that still exists and the likelihood of real breakage

On Wed, May 15, 2024 at 9:27 PM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

1% is a *lot*. Did UKM reveal anything interesting about this usage? Do we know if all of it is driven by site content, vs e.g. extensions? 

On Wed, May 15, 2024 at 9:36 PM Vladimir Levin <vmp...@chromium.org> wrote:

I recall that some of this usage was feature detected: if mutation events are supported, use them; otherwise, use something else. Unfortunately, that makes it difficult to estimate the expected number of breakages. I agree though that it would be nice to understand the type of usage that still exists and the likelihood of real breakage

That's right - some of the usage is definitely feature-detected. I also believe other usage simply doesn't matter to the functioning of the site. I.e a listener is attached (which triggers the use counter) but it is either never fired or doesn't do anything material if it does fire. See below for a comment on breakage.

P.S. Congrats on being added to the API owners. Thanks for your service. :-)

 

On Wed, May 15, 2024 at 9:27 PM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

1% is a *lot*. Did UKM reveal anything interesting about this usage? Do we know if all of it is driven by site content, vs e.g. extensions? 

I totally agree, 1% is a ton of usage, so it's right to be very careful and concerned about this deprecation. Note that deprecating things with this level of usage isn't unprecedented, as my team and I have successfully (and without major breakage) removed Web Components v0 with >2% usage, and event.path with close to 20% usage. But still, let's be sure we're taking all due precaution.

I looked into the UKM data about three months ago, before I started the experiment to disable all mutation events on Canary/Dev/Beta. I looked at the top ~30 UKM hits and dug into the site's code to see what the usage was. Many (~40% or so?) of the top sites usage was due to quilljs which has since updated their code to not rely on mutation events. Another maybe 10% was due to a Sharepoint 2016 mquery.js utility, for which several folks have requested support from MS, but it's a bit unclear what the plan is. The rest of the sites appeared to have bespoke code looking at mutation events.

You asked about extensions, which is a good question. I don't have a great way to track extensions via UKM, at least that I know of. Let me know if you do! I did receive one bug report that an extension was using mutation events, and the extension author quickly patched the extension. 

Very importantly, on literally none of the sites I investigated did I find any broken functionality. That includes the quilljs and mquery sites I mentioned above. Of course, I'm not an expert on those particular sites, and some aren't in my native language. But I could not find the effect of turning off mutation events. Similarly, I've been running my own browser with mutation events disabled for over a year now, and I have yet to find any site with broken functionality. And again, most convincingly to me, I've had these events disabled for all of Canary, Dev, and Beta for the better part of three months, and I've only received the one bug mentioned above about an extension. While that's not a guarantee that nothing will break, of course, I view it as a very strong sign that the effect of turning off these events will be less than what the 1% use counter would suggest.

And finally, of course, assuming I'm approved to disable in M127, I'll be very mindful of breakage and will flip the events back on immediately in the case that there is more breakage than I'm expecting.

I looked into the UKM data about three months ago, before I started the experiment to disable all mutation events on Canary/Dev/Beta. I looked at the top ~30 UKM hits and dug into the site's code to see what the usage was. Many (~40% or so?) of the top sites usage was due to quilljs which has since updated their code to not rely on mutation events. Another maybe 10% was due to a Sharepoint 2016 mquery.js utility, for which several folks have requested support from MS, but it's a bit unclear what the plan is. The rest of the sites appeared to have bespoke code looking at mutation events.

Is Sharepoint 10% of the 1% usage? According to the thread you linked they will fix it in a Sept 2024 release but seem like they won't backport the fix to previous versions. That seems a bit risky, but also I'm not sure what the breakage looks like and as you say, things seem to work.

And finally, of course, assuming I'm approved to disable in M127, I'll be very mindful of breakage and will flip the events back on immediately in the case that there is more breakage than I'm expecting.

Is the plan to do a finch rollout, something like 1% stable increasing week by week? Or were you just thinking of enabling it in 127 without finch?

I had a slight concern about the quilljs usage - even though they've minted a new version, we know that getting sites to update is a major hurdle. That said, after reading through the comments and linked issues on upstream repos (react-quill, etc) - nobody seems to be describing any breakage, they just want the warning to go away. :)

On 5/20/24 1:09 AM, Domenic Denicola wrote:

LGTM2. This is extremely exciting. I hope that in a year, the deprecation process is fully complete, and we get to enjoy deleting a lot of code/specs/maybe tests.

I agree with your instinct to go to 100% directly with the 127 release.

On Mon, May 20, 2024 at 12:18 AM Philip Jägenstedt <foo...@chromium.org> wrote:

In https://github.com/WebKit/standards-positions/issues/192 the point is made that there are other events that fire with the same timing as mutation events, so this removal doesn't unblock everything. Nevertheless, I share the assessment that mutation events "significantly increase the complexity of adding new features to the Web"  so if removal is within reach I think we should go for it. From https://github.com/mozilla/standards-positions/issues/807 it's clear that there is enthusiasm beyond the Chromium project too.

Rolling this out with Finch is definitely prudent, and I agree with the argument for going directly to 100% in 127 to make for a less confusing debugging experience.

LGTM1 to this plan, while being ready to adapt to things that come up in the process.

Thank you all! I will proceed cautiously. A few comments below...

On Tue, May 21, 2024 at 6:37 AM Mike Taylor <mike...@chromium.org> wrote:

I had a slight concern about the quilljs usage - even though they've minted a new version, we know that getting sites to update is a major hurdle. That said, after reading through the comments and linked issues on upstream repos (react-quill, etc) - nobody seems to be describing any breakage, they just want the warning to go away. :)

I agree that in all of the cases where I've seen public issues discussing this, it was just users saying there was a funny warning that made them uncomfortable, not reporting something "broken". Which is good on two fronts: 1) things might not break, and 2) console warnings do work sometimes!

On 5/20/24 1:09 AM, Domenic Denicola wrote:

LGTM2. This is extremely exciting. I hope that in a year, the deprecation process is fully complete, and we get to enjoy deleting a lot of code/specs/maybe tests.

I look forward to deleting that code/spec also! That's the dopamine reward at the end of all painful deprecations. 

I agree with your instinct to go to 100% directly with the 127 release.

Thanks.

On Mon, May 20, 2024 at 12:18 AM Philip Jägenstedt <foo...@chromium.org> wrote:

In https://github.com/WebKit/standards-positions/issues/192 the point is made that there are other events that fire with the same timing as mutation events, so this removal doesn't unblock everything. Nevertheless, I share the assessment that mutation events "significantly increase the complexity of adding new features to the Web"  so if removal is within reach I think we should go for it. From https://github.com/mozilla/standards-positions/issues/807 it's clear that there is enthusiasm beyond the Chromium project too.

The team working on the "state preserving atomic moves" API has managed to navigate around all of the other such synchronous events, leaving only mutation events in their way. So I actually do believe this removal unblocks a new, cool API that is in the works this year. 

Rolling this out with Finch is definitely prudent, and I agree with the argument for going directly to 100% in 127 to make for a less confusing debugging experience.

Thanks. At least two votes for straight-to-100%, so that's what I'll do.