I use AdBlock for that, it takes just a few seconds to compose a blocking rule.
The most brutal and 100% working solution would be to use Proxomitron, dunno if they updated their https certificate though, otherwise it won't parse secure pages.
I wasn't speaking from the perspective of a user --- this is the Script Development sub-forum :-)
From the perspective of a UserScript author, if you're trying to improve a very script-heavy site, you don't want to have your UserScript users *also* having to install some other UserScript or Addon (AdBlock in this case) in order to make yours work; rather you want a direct approach.
On that basis, I'm canvassing for same/similar approaches and/or other things people do to "prepare" the target site for improvement.
You can't block it completely with GM Script, unless you can make the script crash (i.e. hook browser functions that's required in target script and throw error when called).
If you're using Firefox, maybe you can intercept the traffic (see also MDN), strip it the way you want and then feed the browser the new one? Or, if modifying the html via nsITraceableChannel listener is too much of a hassle, at least it'd be quite easy to block non-embedded scripts by url in the http-on-modify-request observer. BTW, the latter method is used by AdBlock+ for Firefox.
Unfortunately this method doesn't work in Chrome and most likely its developers will never add anything of the kind.
@JixunMoe said: "You can't block it completely with GM Script"
Do you know what types of JavaScript execution are *not* caught by blocking propagation of the 'beforescriptexecute' event?
I was thinking that a *completely* inline event handler (no user-defined functions) like the following wouldn't be caught by it and also wouldn't be caught by deleting 'script' elements @ document-start:
< window onload="document.location.href=\"http://foo.bar\"">
I can't think of anything else. Thoughts?
@wOxxOm said: "maybe you can intercept the traffic"
I guess you *could* try to intercept it before it's ever injected into the document (except obviously for inline scripts), but what in your opinion is better about that than using 'beforescriptexecute' to block the execution of the scripts *after* they're injected into the document?
@wOxxOm said: "BTW, the latter method is used by AdBlock+ for Firefox."
And it can do that because as an addon it has access to privileged APIs... I wasn't aware that UserScripts could access the non-web (and non GM) platform APIs... can they? If so, what are the security rules/implications for UserScripts accessing the platform APIs?
In any case, isn't
@ run-at: document-start
a bit too late to be intercepting inline scripts in the HTML page itself from being downloaded?
@"David Toso" Your script saved my but I relatively new in JS and I was building a script and needed to stop custum "tags" attributes "data-rocketsrc=" that a website use RocketScript to cache the JS and checkforbadjavascripts.js did not work with those custom tags. Just tested it and it work perfectly, I will just tweak it to target one script.
I was looking to learn more about "beforescriptexecute" and I've found this thread, so happy. :smiley:
I Will leave some links here I found about blocking replacing scripts, so if somebody else Google for the information and come here it will find it.
CheckScripts.js This is a utility function, meant to be used inside a Greasemonkey script that has the "@run-at document-start" directive set. It Checks for and deletes or replaces specific
Completely kill site-supplied scripts running on a page
So you've got a particularly bloated site that has many, many different scripts loading and executing many, many things asyncrhonously. In your userscript you'd like to strip it back to bare bones and build it back up to something reasonable:
In the UserScript header:
At UserScript execution time:
// remove inline-script tags $('script').remove(); // cancel execution of and remove any scripts that were in the process of loading when we started window.addEventListener('beforescriptexecute', function(e) { e.stopPropagation(); e.preventDefault(); $(e.target).remove(); }, true)That's worked for me so far. The onBeforeScriptExecute doesn't interfere with @require nor with anything you inject into the page after DOMContentLoaded, so you can directly target the site-supplied scripts only :-)
If you only want to block *specific* scripts, you can examine e.target.src or e.target.text in the 'beforescriptexecute' event handler.
I've also tried adding $('script').remove() to 'load' and 'DOMContentLoaded' event handlers, but it never seems to find anything to kill (assuming 'beforescriptexecute' & '@document-start') have been implemented.
Anyone got any other suggestions for a scorched-earth approach to cleaning up a 3rd party page?