New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 193 users

Issue metadata

Status: WontFix
Closed: Apr 2016
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Feature

Show other hotlists

Hotlists containing this issue:

Sign in to add a comment

Issue 168175: add support for afterscriptexecute

Reported by, Jan 3 2013

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.24 (KHTML, like Gecko) Chrome/26.0.1373.0 Safari/537.24

Steps to reproduce the problem:
1. Listen for the afterscriptexecute on script tags. 
2. wait forever

What is the expected behavior?

What went wrong?
afterscriptexecute is never called

Did this work before? N/A 

Chrome version: 26.0.1373.0  Channel: canary
OS Version: OS X 10.8.2

This is currently supported in Firefox and Opera, it would be great to have in Chrome

Comment 1 by, Jan 4 2013

Labels: -Webkit-JavaScript -Type-Bug -OS-Mac WebKit-Core Type-Feature OS-All Area-WebKit Area-Compat
Status: Untriaged

Comment 2 by, Mar 10 2013

Project Member
Labels: -WebKit-Core -Type-Feature -Area-WebKit -Area-Compat Cr-Content Type-Compat Cr-Content-Core

Comment 3 by, Apr 5 2013

Project Member
Labels: -Cr-Content Cr-Blink

Comment 5 by, Aug 7 2013

I need to watch as JS <script> tags get added to the page, and executed. I use the webRequest extension API as a workaround. That works fine, but bfcache items don't fire webRequest events, so if the page is loaded on, say, a browser opening (restoring the page), it looks like the page didn't load anything because it all came from the cache. The Google Web Tracing Framework has people reload the page, and forces the cache off, which is what I do now as well. But sites could do all sorts of things to mess up even these assumptions (dynamic scripts added from JS stored in html comments or localstorage, for example). So this will help in stability (I see what I need to see) and speed (users can use the browser cache!) of my Chrome extension.

Comment 6 by, Aug 19 2013

I've been tracking down a bug for days... then I realized the bug was me. :/

I had been using webrequest.onComplete, filtered for scripts. My error was that I made the incorrect association between the scripts being loaded and being executed. The get loaded in a different order than they get executed, and thus the timing of the events . I need to inject between certain scripts, particularly for YUI3 and BackboneJS, so I need an event right after a file has been executed and before the next one. I can set timeouts for ExtJS and get past some immediate issues, but broad framework support will definitely hinge on this issue. This issue is one solution, but something from privileged code would be better.

The only solution I can think of at the moment is to alter the JS being loaded before it gets executed. But it makes my stomach turn. And the bfcache would wreak even more havoc, so not a great solution either. Maybe I am just missing something?

Comment 7 by, Sep 4 2013

The beforescriptexecute and afterscriptexecute events can be emulated for non-inline scripts using the beforeload and load events. This method is elaborated at

Comment 8 by, Mar 23 2014

Labels: -Type-Compat Type-Feature
Status: Started
beforeload is going away, so the work-around in my previous comment doesn't work any more.

I'm going to add a standard-compliant beforescript/afterscriptexecute implementation to Blink.

Comment 9 by, Apr 13 2014

beforeload was yanked out, but beforescript/afterscriptexecute was not added at the same time?

Comment 10 by, Apr 13 2014

@sroussey (#9)
I uploaded a CL (,
but there are mixed responses towards adding the feature:

Comment 11 by Deleted ...@, Jun 18 2014

Hey guys, any status on this? Would be a wonderful feature!

Comment 12 by, Apr 14 2015

Still missing and need this feature

Comment 13 by, Jul 15 2015

Labels: -Cr-Content-Core

Comment 14 by, Sep 9 2015

Beforescriptexecute and afterscriptexecute are official html5 events that should be supported. There's a testcase wt w3c, chrome fails the tests:

Comment 15 by, Sep 26 2015

How hard can it be?

Comment 16 Deleted

Comment 17 by, Oct 7 2015

Come on, it's almost 3 years now. Firefox supported it already. Why is it not supported in Chrome?

Comment 18 by, Oct 19 2015

This is very important functionality. The developers of AdBlock Plus (one of the most installed addons) need this to implement a new feature:
But they can't because Chromium developers refuse to implement a feature that is officially part of the W3C HTML5 standard.

Therefore Chromium browsers fail certain HTML5 tests, like this one:
Firefox passes all these tests.

I thought Chromium is all about supporting standards like HTML5?

Comment 19 by, Oct 19 2015

Whoa there Herbert. Accusing the Chromium team of not supporting HTML5 based on missing a single feature is hardly fair haha. Every browser is missing a bunch of official pieces of the HTML5 spec, and Chromium is still leading the pack in HTML5 support by a wide margin overall.

I'm all for afterscriptexecute (or something like it) being supported, but another Googler makes a good point in the thread Rob linked in post #10 above:

It's a good feature, but maybe it really does make more sense as an extension API instead.

Comment 20 by, Dec 2 2015

"Status: Started"

Sounds good, does that mean it will be implemented?

Comment 21 by, Dec 2 2015

Comment 22 by, Dec 2 2015

Status: Available
"Status: started" means that there is/was work in progress.

But there is much valid opposition against the feature, and no strong use cases to offset the concerns. So I've retracted my support for the implementation, and it's not likely that this feature gets implemented in Chrome.

Comment 23 by, Dec 2 2015

Valid opposition? I thought it was part of HTML5?

Or was that some kind of slight exaggeration? Whatever, I certainly do not know enough about the subject, so I just hope that you know what you are doing. ;-)

Nevertheless, 99 stars currently, that is certainly not your average issue, so I guess the demand is there.

But maybe there is another way, so that same or similar results can be achieved on another route, you know, many ways lead to Rome.

But I'm just speculating here ;-)

Comment 24 by, Dec 8 2015

Can one of the developers please take 2 minutes out of your day and fix this issue?..

This issue has over 100+ stars already.. How many more hundreds of stars does it need before the developers realize that people really want this issue implemented??..

To comment #22: Even if there is opposition from some people some where, there is also a lot of people that advocate implementing this feature; otherwise it wouldn't have 100+ stars.. Furthermore, it is a HTML5 standard.. So it should be implemented, and any one who has a problem with it needs to go through the W3C channels and tell them to remove the specification from the HTML protocol.. After that it can be removed from chromium.. But if different browsers just pick and choose which HTML5 features they feel like or don't feel like implementing, it causes the whole internet to become an erratic mess where any particular webpage will randomly work on some browsers, and it won't function properly on others.. That is the whole point of the W3C..

Firefox has had this implemented already since 400 B.C.
The "valid opposition" from some of the developers is that this feature could allow some extension developers to create malicious extensions that inject code on every page after scripts execute.. But how many evil extensions like that has any one realistically installed?.. And you could just uninstall any way..
Does firefox seem over-ridden with evil extensions every where injecting code because they implemented this HTML5 standard?.. Hint: Nope.

Comment 25 by, Dec 8 2015

I'm curious why there is so many comments with "firefox had this implemented many years ago" - do You really thing that this could be motivating? Usual developer looking on such msg would answer "so use firefox or be less offensive".

Google is company mostly taking profit from advertisement and probably they do not have workaround for adblocker using this technique, so try to understand that it would be unpolitical to add feature without workaround, which could harm revenue and is mostly used in adblockers...

Argumentation that this is the W3C standard - hides behind business choices, please remember this...

Comment 26 by, Dec 8 2015

The feature could be implemented and just disabled by default, so you have to enable it via flags. This wouldn't decrease the security of the browser and satisfy all the _advanced_ users who _demand_ this feature.

Comment 27 by Deleted ...@, Dec 8 2015

What is security problem? What is flag to enable afterscriptexecute? Found no information in Internet. Users do not demand features. Developers deliver.

Comment 28 by, Dec 9 2015

#27: I'm sorry, but what are you trying to say?!

For the reference:

Firing 'beforescriptexecute' and 'afterscriptexecute' is explicitly mentioned in this section:

"When the user agent is required to execute a script block, it must run the following steps:" 

See 2.2 respectively 2.9:

Comment 29 by, Jan 19 2016

>> But there is much valid opposition against the feature

Could you shed some light on this? Why Chrome team prevents web site owners to block malicious script execution? Also, recently they have changed Subresource Integrity, it must be read/write (WHATWG), but after changes it is like read-only, if you set a wrong hash - script execution will not be blocked. Why and who lobbies malware authors?

Comment 30 by, Jan 21 2016

when this be get solved ???

Comment 31 by, Jan 21 2016

this request is 3 years old and still stuck in "persuasion hell"

Comment 32 by, Jan 21 2016

Instead of simply complaining that this isn't implemented, why don't you guys lay out your use cases and explain how they can't be solved by other solutions?

The consensus among the Chromium devs currently seems to be that a) this feature isn't worth blocking the paser for, b) it's not useful outside of extensions, and c) all valid use cases for this feature can be covered using custom elements, service workers, or ES6 modules:

Comment 34 by, Jan 27 2016

One use case is for advert/tracker blocker, such as uBlock Origin which can block inline script if the browser support beforescriptexecute event ( Firefox already supports this.
This feature is an attempt to stop anti-blocker scripts in various websites.

Comment 35 by, Feb 8 2016

is it so hard to implement this feature ? 3years wtf...

Comment 36 by, Feb 8 2016

this issue have no easy/hard problem.

it's political problem - google is company based mostly on advertisement and this feature is mostly used (in other browsers) in adblockers.

it's classical knife/riffle problem - should we ban production/distribution of knives (like guns), because they can be used with bad intentions?

Comment 37 by, Feb 8 2016

Hm... I think Google's ads have nothing to do here. The only reason is lack of real life use-cases outside of adblocking extensions. Andrew told this in comment #32 already. If someone have a real use-case which is not possible to implement without this then tell it already. Maybe it will change something.

On the other hand it looks like soon it will be possible to use that polyfill from comment #33 which will let us to attach a script to a SCRIPT tag and run it before or after the content of the tag. So, looks like relatively soon (that polyfill didn't worked for me in Chrome 49-beta) this issue will be resolved in one way or another even if actual event won't be implemented.

Comment 38 by, Feb 8 2016

Hm... That polyfill from comment #33 disappeared from the github. Strange.

Comment 39 by, Feb 8 2016

As i remember, this polyfill loads the page twice, so it's not a good polyfill.

Comment 40 by, Feb 16 2016

Oh hey the polyfill is back.

With an explainer section at the top for idiots.

Comment 41 by, Feb 16 2016

Labels: -Cr-Blink Cr-Blink-Loader

Comment 42 by, Feb 16 2016

I will add an implementation that uses no Es2015 features. Stay tuned to that gist. It is ok to use code from that gist to include in a patch for Chromium, cla-signed contributor, Dosaygo.

Comment 43 by, Feb 17 2016

Actually it's not really possible to do a polyfill without using service workers.

Comment 44 by, Mar 25 2016

Those who are following this issue may also be interested in subscribing to , which discusses the future of beforescriptexecute / afterscriptexecute.

Comment 45 by, Apr 23 2016

Status: WontFix (was: Available)
The beforescriptexecute/afterscriptexecute events have been removed from the specification (, and they will not be implemented in Chrome.

Comment 46 by, Apr 23 2016

…and they got removed exactly because Chrome didn't implemented them for so long and nobody else did. And we all know MS and Apple wouldn't budge to implement something like this first. -_-

Comment 47 by, Apr 23 2016


Comment 48 by, Apr 23 2016

HAHA glad I use firefox instead of crapium.. You know your corporate over-lords don't want you to use things like ublock which might affect their precious little profit margins.. See ya later losers! lololol

Comment 49 by, Apr 27 2016

Maybe we can use new JS features (Proxy, WeakMap) to intercept or wrap around the script execution from Chrome extension. There's an example of a wrapper around WebSocket API created by the developer behind uBlock Origin.
See detail here

Comment 50 by, May 10 2016

What is the alternative for inside an extension?

Comment 51 by, May 11 2016

It's time to switch to Firefox. Malicious adverts are evolving and we need all the support we could get from browsers.

Comment 52 by, May 11 2016

"removed from the specification" ? and the alternative ? Are you thinking to the users or you are on other planet ?

Comment 53 by, May 11 2016

I guess you're right, #51

I don't like to say this, but maybe it really is time to switch back to Firefox..

Comment 54 by, May 17 2016

A workaround for Chrome users is to turn off JS everywhere, except where you're absolutely sure that there's no advert/tracking or where you allow the website to run advert/tracking code on your browser.

Comment 55 by, Jun 18 2016

Honestly, the main reason I use an adblocker is for system security. And given the current state of Firefox sandboxing, switching to it borders on the cure being worse than the disease.

There's other ways around adblocker detection anyway.

Comment 56 by, Jun 27 2016

#55: what do you mean by "There's other ways around adblocker detection anyway" ?

Comment 57 Deleted

Comment 58 by, Apr 29 2017

Congratulations for proving yourselves as ad-business ass-lickers again, devs!

Comment 59 by, Apr 29 2017

My unfortunate solution to this issue is simply using setTimeout(myFunction,1) where myFunction checks if the other script is available and if not calls setTimeout(myFunction,1) again. This of course isn't ideal and if the script isn't ever found this can lockup the entire page.

Comment 60 by, Jul 30 2017

This works perfectly when cache is disabled by DevTools. Tested in Chrome 60. 

I think something is broken about cache handling since the script element *sometimes* don't have textContent when my event is dispatched. 

Only works for "hard coded" scripts. Have fun :)

Comment 61 by, Jul 30 2017

I think patching eval and Element.prototype.append (and related functions) can be used to interfere dynamically generated scripts, hard coded scripts can be canceled only when the page is not cached... Actually, it can always be canceled but without textContent, you are left guessing which one to cancel. 
For afterscriptexecute, just append your payload to the end of the script that is about to execute.

Sign in to add a comment