1584269 - Unimplement onafterscriptexecute and onbeforescriptexecute events (and attributes)

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, task)

Description

[Frederik Braun [:freddy]]

I suggest we unship the events and attributes.
This is in the document and the script element implementation.

See also https://developer.mozilla.org/en-US/docs/Web/API/Document/onafterscriptexecute

Comment 1

[Tom S. (please needinfo tschuster)]

http://wpt.live/html/semantics/scripting-1/the-script-element/historical.html

Comment 2

[Jan Henning [:JanH]]

If they're no longer available to regular web content fine, but aren't these events still quite useful for extensions in general and user scripts in particular that want to intercept script loading?

I've only recently needed to edit a page's script before it is executed in order to fix some bug for me, and all the results I've found on how to achieve that with Greasemonkey et al. pointed to beforescriptexecute as the best solution for Firefox (and it did indeed work out nicely that way).
Also compare https://bugzilla.mozilla.org/show_bug.cgi?id=1286822#c1

Comment 3

[Frederik Braun [:freddy]]

Don't Content Scripts give you the guarantee of executing first?

Comment 4

[Jeff Muizelaar [:jrmuizel]]

If we're worried about this causing compatibility problems we could consider not sending these events on a per-origin basis. That would at least let us unblock the pge.com problem.

Comment 5

[Simon Pieters [:zcorpan]]

I can look at httparchive to see how commonly used these are.

Comment 6

[Simon Pieters [:zcorpan]]

589,566 pages out of 12,851,198 (~4.59%) have "beforescriptexecute" or "afterscriptexecute" in httparchive.response_bodies.2024_11_01. It seems very risky to remove.

Pages by rank:
https://docs.google.com/spreadsheets/d/1r7u2UEwZsvH4vlCPCkEnxiy2GIoxM-zHF2CgmR26s_M/edit?usp=sharing

More detailed results with resource urls and extracts:
https://docs.google.com/spreadsheets/d/1i4VNEIZFYTiAcaDYg1aK02mMB5nhgg6kWdCaRBZVcAA/edit?usp=sharing

Comment 7

[Jeff Muizelaar [:jrmuizel]]

I don't think the existence of beforescriptexecute/afterscriptexecute suggests that removing support will cause webcompat problems. We only care about situations where a site would be doing something like UA sniffing Firefox and using beforescriptexecute/afterscriptexecute and not relying on what ever mechanism they're using in Chrome.

I think we just need to try, see what breaks, and then have interventions that change the behaviour on a per origin basis in one way or the other.

Comment 8

[Jeff Muizelaar [:jrmuizel]]

At the same time we should probably do outreach to common users like https://consent.cookiebot.com/uc.js, https://cdn.cookielaw.org/consent/27cca70a-7db3-4852-9ef0-a6660fd0977d/OtAutoBlock.js and https://static.adsafeprotected.com/sca.17.6.4.js to see if we can get them to stop using it.

Comment 9

[Frederik Braun [:freddy]]

One could also keep the functionality of UA-sniffing code like "object"==typeof document.onafterscriptexecute alive while removing the event handler code. This wouldn't be a first.

A UseCounter for document property access vs. actual event handler in markup would help shed some light on this.

Comment 10

[Simon Pieters [:zcorpan]]

:jrmuizel, true, but a lot of instances seem to use event listeners for these. We can drop the events and attributes behind a flag and then manually check how the top sites in the httparchive list are affected.

Comment 11

[Simon Pieters [:zcorpan]]

Here are the script urls sorted by how many pages are using it:

https://docs.google.com/spreadsheets/d/1d9cEeDmoeiR3VH1eQLLJMtVr5kTk_7htMj0nG-Zu1vQ/edit?usp=sharing

Comment 12

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Adding tentative scheduled info to hint that it's on our backlog, and we will try this out.

Comment 13

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Assigning this to Edgar, who will firstly add telemetry and ensure we keep the ball rolling here.

Comment 14

[Jeff Muizelaar [:jrmuizel]]

FWIW, I don't know that the telemetry will be super helpful in making a decision here. It's going to be very hard to distinguish between uses of beforescriptexecute that are needed vs. ones that are not. If we just want to use the telemetry to track usage over time then that could be useful.

Some things that could help move the needle here:

1. Updating https://developer.mozilla.org/en-US/docs/Web/API/Document/beforescriptexecute_event etc. to say that the events are deprecated and will be removed.
2. Adding warnings to the console when they're used.
3. Turning them off in Nightly

Comment 15

[Jeff Muizelaar [:jrmuizel]]

I've also gotten confirmation from OneTrust that they are looking into removing their use of beforescriptexecute

Comment 16

[Jan Henning [:JanH]]

Can I ask again, what's the replacement story for user scripts and the like supposed to be?

beforescriptexecute provides a very handy hook to override a page's scripts via user scripts. (E.g. I've come across a page that breaks the session store's form input data saving by clearing out all input fields on page load, which also clears out any data restored by the session store. With the help of beforescriptexecute, I've been able to write an user script that removes that behaviour on-the-fly while keeping the rest of the page's scripts intact.)

Having to write a full extension utilising web request filtering seems much more heavyweight in comparison.

Comment 17

[Jeff Muizelaar [:jrmuizel]]

How are you injecting the user script?

It's possible to block scripts by setting their type to text/plain. That's what these script blockers do:
https://github.com/pressidium/pressidium-cookie-consent/blob/de9983548184a916ebd28d8b38d240ba14e17adc/src/client/block-scripts.js#L119
https://github.com/ScriptedAlchemy/yett/blob/0d244ec739911f14e1865d64eb4f66eb3239f80f/src/observer.js#L20

Comment 18

[Jan Henning [:JanH]]

How are you injecting the user script?

Greasemonkey/Violentmonkey et al.

Okay I see, so scanning for any pre-existing <script> elements already present in the DOM, processing them and then adding a mutation observer to catch any <script> elements added afterwards might work, too. I need to try it out, but thanks for the inspiration, this does look like a possible workaround.

Comment 19

[Holger Benl [:hbenl]]

I've looked a bit into the use of beforescriptexecute by script blockers because they were causing webcompat issues on multiple sites.
All the blockers I've looked at use the techniques described in this article: https://medium.com/snips-ai/how-to-block-third-party-scripts-with-a-few-lines-of-javascript-f0b08b9c4c0.
For scripts that are not added programmatically, they use a MutationObserver that changes the type attribute of any added <script> element that they want to block. The article states that this doesn't block the script in Firefox though and uses a beforescriptexecute handler to block the script. But this information is outdated - the technique does work in current Firefox. So all those script blockers should simply remove their use of beforescriptexecute as changing the type attribute will now have the same effect in Firefox as in Chrome.

So how did this end up causing webcompat issues? The MutationObserver also handles programmatically added <script> elements and erroneously decides it wants to block some of them. According to the article that should not have any effect - changing the type and calling preventDefault() in the beforescriptexecute handler should not block programmatically added <script> elements. But in current Firefox the beforescriptexecute handler does block them.

Comment 20

[Sebastian Zartner [:sebo]]

Regarding the documentation, once they are removed completely, the compat data for the two events should be updated, see

https://github.com/mdn/browser-compat-data/blob/8395f1e832de3e687fd6b83027c334f6f7b81173/api/Document.json#L348
https://github.com/mdn/browser-compat-data/blob/8395f1e832de3e687fd6b83027c334f6f7b81173/api/Document.json#L718

Maybe, for completeness, the page https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/script and the related compat data should also be updated to include the attributes onbeforescriptexecute and onafterscriptexecute.

Sebastian

Comment 21

[Rob Wells]

(In reply to Holger Benl [:hbenl] from comment #19)

For scripts that are not added programmatically, they use a MutationObserver that changes the type attribute of any added <script> element that they want to block. The article states that this doesn't block the script in Firefox though and uses a beforescriptexecute handler to block the script. But this information is outdated - the technique does work in current Firefox. So all those script blockers should simply remove their use of beforescriptexecute as changing the type attribute will now have the same effect in Firefox as in Chrome.

I've found that MutationObserver in Chrome allows for beforescriptexecute-like behaviour, but in Firefox it does not work to prevent script execution.

I've created a minimal example that has different behaviour in Firefox (139) and Chrome (137), at https://github.com/robjwells/ff-beforescriptexecute . The HTML file sources a script that sets an event listener on the button. In Chrome the userscript can prevent the execution of the script, and the addition of the event listener, but in Firefox it cannot.

Comment 22

[Rob Wells]

Further to my previous comment, the behaviour changes if the script to be intercepted has the defer attribute set. I've also simplified the example to remove the need for user interaction.

If the script is marked defer, changing the type has no effect. If it is not marked defer, changing the type prevents the script from executing.

Comment 23

[Edgar Chen [:edgar]]

Thanks for reporting this, Rod! I’ve split it into bug 1973704.

Comment 25

[Edgar Chen [:edgar]]

Attachment: Bug 1584269 - Unship onafterscriptexecute and onbeforescriptexecute events by default; r?hsivonen

Comment 26

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/56bf35ad2666
https://hg.mozilla.org/integration/autoland/rev/bbdb0a95a152
Unship onafterscriptexecute and onbeforescriptexecute events by default; r=hsivonen

Comment 27

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/bbdb0a95a152

Comment 28

[Hamish Willee]

FF144 MDN docs work can be tracked/viewed in https://github.com/mdn/content/issues/41141