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 175 users
Status: WontFix
Owner:
Closed: Apr 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Feature


Show other hotlists

Hotlists containing this issue:
Hotlist-1


Sign in to add a comment
add support for afterscriptexecute
Reported by patrickk...@gmail.com, Jan 3 2013 Back to list
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 tkent@chromium.org, Jan 4 2013
Cc: tonyg@chromium.org
Labels: -Webkit-JavaScript -Type-Bug -OS-Mac WebKit-Core Type-Feature OS-All Area-WebKit Area-Compat
Status: Untriaged
Project Member Comment 2 by bugdroid1@chromium.org, Mar 10 2013
Labels: -WebKit-Core -Type-Feature -Area-WebKit -Area-Compat Cr-Content Type-Compat Cr-Content-Core
Project Member Comment 3 by bugdroid1@chromium.org, Apr 5 2013
Labels: -Cr-Content Cr-Blink
Comment 5 by srous...@gmail.com, 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 srous...@gmail.com, 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 robwu...@gmail.com, 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 http://stackoverflow.com/a/18608622/938089.
Comment 8 by rob@robwu.nl, Mar 23 2014
Labels: -Type-Compat Type-Feature
Owner: rob@robwu.nl
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 srous...@gmail.com, Apr 13 2014
beforeload was yanked out, but beforescript/afterscriptexecute was not added at the same time?
Comment 10 by rob@robwu.nl, Apr 13 2014
@sroussey (#9)
I uploaded a CL (https://codereview.chromium.org/209593002/),
but there are mixed responses towards adding the feature:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/bChX6leKqtg/Idut6cE4ORcJ
Comment 11 by Deleted ...@, Jun 18 2014
Hey guys, any status on this? Would be a wonderful feature! 
Comment 12 by xue...@gmail.com, Apr 14 2015
Still missing and need this feature
Comment 13 by tkent@chromium.org, Jul 15 2015
Labels: -Cr-Content-Core
Beforescriptexecute and afterscriptexecute are official html5 events that should be supported. There's a testcase wt w3c, chrome fails the tests:
http://www.w3c-test.org/html/semantics/scripting-1/the-script-element/script-before-after-events.html
Comment 15 by seth...@gmail.com, Sep 26 2015
How hard can it be?
Comment 16 Deleted
Come on, it's almost 3 years now. Firefox supported it already. Why is it not supported in Chrome?
This is very important functionality. The developers of AdBlock Plus (one of the most installed addons) need this to implement a new feature: https://issues.adblockplus.org/ticket/3207
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: http://www.w3c-test.org/html/semantics/scripting-1/the-script-element/script-before-after-events.html
Firefox passes all these tests.

I thought Chromium is all about supporting standards like HTML5?
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: https://groups.google.com/a/chromium.org/d/msg/blink-dev/bChX6leKqtg/2FR3SQ_ArpcJ

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

Sounds good, does that mean it will be implemented?
Comment 21 by lgr...@gmail.com, Dec 2 2015
@#20
https://goo.gl/Fn1ofg
Comment 22 by rob@robwu.nl, 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 hora...@gmail.com, 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 yas...@gmail.com, 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.
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...
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.
#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:

https://html.spec.whatwg.org/#execute-the-script-block


Comment 29 by ret...@gmail.com, 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? 
when this be get solved ???
Comment 31 by dungs...@gmail.com, Jan 21 2016
this request is 3 years old and still stuck in "persuasion hell"
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:

https://groups.google.com/a/chromium.org/d/msg/blink-dev/bChX6leKqtg/ERUnT1TrIsgJ
Comment 34 by dungs...@gmail.com, 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 (https://github.com/gorhill/uBlock/wiki/Inline-script-tag-filtering). Firefox already supports this.
This feature is an attempt to stop anti-blocker scripts in various websites.
is it so hard to implement this feature ? 3years wtf...
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?
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.
Hm... That polyfill from comment #33 disappeared from the github. Strange.
Comment 39 by cool...@gmail.com, Feb 8 2016
As i remember, this polyfill loads the page twice, so it's not a good polyfill.
Oh hey the polyfill is back. https://gist.github.com/dosaygo/eae5f18db07fa97db5e6

With an explainer section at the top for idiots.
Labels: -Cr-Blink Cr-Blink-Loader
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.
Actually it's not really possible to do a polyfill without using service workers. 
Comment 44 by rob@robwu.nl, Mar 25 2016
Those who are following this issue may also be interested in subscribing to https://github.com/whatwg/html/issues/943 , which discusses the future of beforescriptexecute / afterscriptexecute.
Comment 45 by rob@robwu.nl, Apr 23 2016
Status: WontFix
The beforescriptexecute/afterscriptexecute events have been removed from the specification (https://github.com/whatwg/html/pull/1103), and they will not be implemented in Chrome.
…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 cool...@gmail.com, Apr 23 2016
noooooooooooooooooooooooooooooooooooooooooooooooo!
Comment 48 by yas...@gmail.com, 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 dungs...@gmail.com, 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 https://github.com/gorhill/uBlock/issues/1497
Comment 50 by srous...@gmail.com, May 10 2016
What is the alternative for inside an extension?
Comment 51 by dungs...@gmail.com, 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.
"removed from the specification" ? and the alternative ? Are you thinking to the users or you are on other planet ?
Comment 53 by hora...@gmail.com, 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 dungs...@gmail.com, 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.
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 dungs...@gmail.com, Jun 27 2016
#55: what do you mean by "There's other ways around adblocker detection anyway" ?
Comment 57 Deleted
Congratulations for proving yourselves as ad-business ass-lickers again, devs!
Comment 59 by ren...@arimil.com, 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.
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 :)

https://gist.github.com/jspenguin2017/cd568a50128c71e515738413cd09a890

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