Userscripts are used by add-ons like Greasemonkey. But how can I utilize these scripts in my site?
For example, I found a script could eliminate ads in videos, and I want to put this script in my site, so people in my site wont't see those ads
I've tried just to save and put it in <script> in the head, but something just went wrong.
(TypeError: document.body is null)
I also tried to put it just before </body>, no error reported this time, but something still doesn't work.
And I'm wondering how Greasemonkey works? Does it just insert scripts in the webpage? How does it load scripts into the pages?
Greasemonkey and Userscripts.org are meant to provide kind of lightweight extensions for the browser, not for the webpages. I.e. you install them as the user inside your browser.
Some of the trivial scripts might be incorporated into webpages, but in general, Greasemonkey has some "superpowers" to do things that ordinary JavaScript can't do due to security constraints. For instance, issuing (and reading response of) cross-domain XMLHttpRequest, interactions between frames from different origin etc.
Normally Greasemonkey scripts are executed when DOMContentLoaded is fired by the browser (this can be changed using #run-at directive to execute the script before anything is loaded).
If the script has #grant none in its GM meta section, then it could be perhaps incorporated into your site, but it depends on what it exactly does.
Bear in mind also that Greasemonkey is a Firefox extension (there's equivalent extension for Chrome and also some limited native support from Chrome and Opera). Many userscripts will likely fail in IE8.
Related
I have a bookmarklet script but in some browsers (for example firefox) it cannot be executed on pages with a certain content security policy (it does not depend on the script itself, firefox just won't execute any part of the script at all on these pages). So is there any way to have some kind of fallback routine when firefox or other browsers block the script, maybe in a way that a certain url is opened without js?
Edit: Mozilla doesn't seem to be interested in the CSP Level 3 guidelines (§ 9.1):
Policy enforced on a resource SHOULD NOT interfere with the operation
of user-agent features like addons, extensions, or bookmarklets. These
kinds of features generally advance the user’s priority over page
authors, as espoused in [HTML-DESIGN].
(https://www.w3.org/TR/CSP/#extensions)
No.
A bookmarklet is a JS URL. While you might put other kinds of data inside it, it starts out as JS, so if a security policy blocks it, then it blocks the whole thing.
I was facing an issue while developing this small userscript. When I wanted to block every XMLHttpRequest from the running website with my script, nothing was happening (at least with Chrome):
function main() {
// Override XHR.open with a custom function
window.XMLHttpRequest.prototype.open = function() {
// Nothing... so it's supposed to block every xhr.open() call
}
}
main();
Same thing when replacing window by unsafeWindow.
However, when I used this little trick, everything worked like a charm:
// No more call to main(), and:
var script = document.createElement("script");
script.textContent = "(" + main.toString() + ")();";
document.body.appendChild(script);
Every call to xhr.open is replaced by my custom function, no more AJAX.
So I guess the window element is not the same when main is called from inside the script than when it's called from a <script></script> container. Can someone explain me why ?
See "Are Chrome user-scripts separated from the global namespace like Greasemonkey scripts?". Both Chrome userscripts/content-scripts and Greasemonkey scripts are isolated from the page's javascript. This is done to help keep you from being hacked, but it also reduces conflicts and unexpected side-effects.
However, the methods are different for each browser...
Firefox:
Runs scripts in an XPCNativeWrapper sandbox, unless #grant none is in effect (as of GM 1.0).
Wraps the script in an anonymous function by default.
Provides unsafeWindow to access the target page's javascript. But beware that it is possible for hostile webmasters to follow unsafeWindow usage back to the script's context and thus gain elevated privileges to pwn you with.
Chrome:
Runs scripts in an "isolated world".
Wraps the script in an anonymous function.
Strictly blocks any access to the page's JS by the script and vice-versa.
Recent versions of Chrome now provide an object named unsafeWindow, for very-limited compatibility, but this object does not provide any access to the target page's JS. It is the same as window in the script scope (which is not window in the page scope).
That said, the version of your script that used unsafeWindow should work on/in Firefox if implemented correctly. It might work using the Tampermonkey extension on Chrome, but I'm not going to double-check that right now.
When you do that "trick" (var script = document.createElement("script"); ...), you are injecting code into the target page. This bypasses the sandbox and is the only way on a normal Chrome userscript for a script to interact with the page's JS.
Injection advantages:
The only way for non-Tampermonkey userscripts to access objects or functions provided by the target page.
Almost always fully compatible between Chrome, Firefox, Opera, etc. (IE is, as always, something else.)
Often easier to debug the whole script; developer tools work normally.
Injection drawbacks:
The script, at least the injected parts, cannot use the enhanced privileges (especially cross-domain) provided by the GM_ functions -- especially GM_xmlhttpRequest().
Note that currently Chrome only supports GM_addStyle, GM_xmlhttpRequest, GM_log and GM_openInTab, fully, natively.
Tampermonkey supports GM_ functions almost fully, however.
Can cause side effects or conflicts with the page's JS.
Using external libraries introduces even more conflicts and timing issues. It's nowhere near as easy as #require.
#require, also runs the external JS from a local copy -- speeding execution and all but eliminating reliance on an external server.
The page can see, use, change, or block the script.
Requires JS to be enabled. Firefox Greasemonkey, especially, can run on a page which has JS blocked. This can be godsend on bloated, crappy, and/or intrusive pages.
I know Greasemonkey scripts are automatically wrapped in anonymous functions isolated in some way in order to prevent them conflicting with scripts in the page.
Does the same happen with Chrome user-scripts?
Yes, Greasemonkey scripts are normally wrapped in an anonymous function. And, Chrome userscripts apparently are too.
But, more importantly, Greasemonkey scripts are usually1 wrapped in an XPCNativeWrapper sandbox, while Google Chrome converts userscripts into extensions, and they operate in an arena that Google calls an "isolated world"2.
So, you don't need to wrap your script code in anonymous functions for security purposes, they're already protected.
Just beware that:
If you inject code directly into the page (create a <script> tag), then that code can be seen by the page's JS.
If you use unsafeWindow, then the page could theoretically follow it back and gain slightly elevated privileges.
The risk is very low, and I haven't been able to find any documented exploits in the wild.
~~~
Bottom line, scripts are isolated to different degrees in both browsers. (And not merely by being wrapped in anonymous functions.)
Greasemonkey has a nice set of privileged features available, in Firefox. While userscripts in Chrome are much more restricted.
However, much of GM's functionality is restored to Chrome via use of the Tampermonkey extension.
1 As of Greasemonkey version 1.0 (August 24, 2012), the sandbox is controlled by the #grant directive. If the script runs with (or defaults to) #grant none, then the sandbox isn't used. The script merely runs in a private scope and the normal GM_, API functions will not work.
2 Doesn't that sound so much bigger/nicer than some nasty sandbox? (^_^)
.
I've got a little problem with UserScripts in Google Chrome, to be precise with getting to the object window of an iframe. Very doable via the Google Chrome console, very impossible via the UserScript or so it seems so far. To be honest it seems as if it was on purpose, as if there was some reason why I'm not allowed to access other window objects.
document.body.innerHTML += "<iframe name='iframe'></iframe>";
console.log(top.frames.iframe);
console.log(window.frames.iframe);
console.log(unsafeWindow.frames.iframe);
console.log(document.getElementsByName('iframe')[0].contentWindow);
console.log(document.getElementsByName('iframe')[0].contentDocument.defaultView);
-->
chrome-extension://eelclpmekkanegjojjmaldeddncficoj/script.js:14 undefined
chrome-extension://eelclpmekkanegjojjmaldeddncficoj/script.js:15 undefined
chrome-extension://eelclpmekkanegjojjmaldeddncficoj/script.js:16 undefined
chrome-extension://eelclpmekkanegjojjmaldeddncficoj/script.js:17 undefined
chrome-extension://eelclpmekkanegjojjmaldeddncficoj/script.js:18 undefined
Might I ask what Chrome's problem is? I don't really get why should a UserScript have lesser access to javascript than a normal script, what are the implications? By the way, yes, the iframe is on the same domain and protocol. :(
UnsafeWindow isn't support by Chrome, try TamperMonkey, pretty sure it provides read-only access to that variable.
contentWindow.document isn't available for Chrome. contentDocument should work.
Also, XMLHttpRequest for cross domains also aren't supported. Most of these are for security purposes. Userscripts in Chrome are content scripts, they cannot access the functions/variables defined by web pages or by other content scripts. It's mostly for security and isolation of scripts, to prevent scripts from conflicting with each other.
As for document.getElementsByName('iframe')[0].contentWindow, I think it's because the way you're trying to add in your iframe. For starters, don't name your iframe as 'iframe', always a very bad practice.
Instead to attempting to add it into the body's innerHTML, use appendChild(), and append a new iframe object into document.body. Also, instead of document.getElementsByName, try document.body.getElementsByName.
I write greasemonkey scripts for firefox, and Chrome seems too restrictive. And I hope you know about the location hack for userscripts. Check out http://wiki.greasespot.net/Location_hack . You can use Javascript in your userscripts ;) And just to let you know right now, I would VERY much warn against messing with iframes and userscripts. I've wrote a script for Greasemonkey, been trying for 6 months, but somehow, when I involve code inside the iframe, half of the time, that result is undefined, and I never get into that problem with javascript. Also, if you inject .js script objects into a document from a userscripts, the new code is still somehow affected, and so how, randomly, elements show up as undefined. After 6 months of trying, I gave up, and I just have a bookmarklet just injects a .js script into documents manually. Of course, you don't have to do that, you can just use a location hack to inject the code from a userscript. But as for writing entire scripts based on userscripts for iframes, I'm staying far far away...
I'm trying to profile the performance of a web site that I'm fairly confident is being slowed down by the loading of JavaScript files on the page.
The same JavaScript files are included several times on the page, and <script /> tags are scattered throughout the page instead of being included at the bottom.
As I suspected, when looking at FireBug's "Net" tab, most of the time (not all) when JavaScript is being loaded, no other files are requested. The browser waits for the JavaScript to complete loading.
There are a few exceptions however. There are a few occasions where JavaScript is loaded, but then at the same time, other resources appear to get loaded, such as other JavaScript files and images.
I always thought that JavaScript blocks the loading of other resources on the page. Am I incorrect in thinking this, or does this behavior vary depending on the browser or browser version?
UPDATE:
To those who have explained how loading a script blocks the loading of other resources, I'm already aware of this. My question is why a script wouldn't block the loading of other resources. Firebug is showing that some JavaScript files do not block loading other resources. I want to know why this would happen.
Javascript resource requests are indeed blocking, but there are ways around this (to wit: DOM injected script tags in the head, and AJAX requests) which without seeing the page myself is likely to be what's happening here.
Including multiple copies of the same JS resource is extremely bad but not necessarily fatal, and is typical of larger sites which might have been accreted from the work of separate teams, or just plain old bad coding, planning, or maintenance.
As far as yahoo's recommendation to place scripts at the bottom of the body, this improves percieved response times, and can improve actual loading times to a degree (because all the previous resources are allowed to async first), but it will never be as effective as non-blocking requests (though they come with a high barrier of technical capability).
Pretty decent discussion of non-blocking JS here.
I'm not entirly sure that Firebug offers a true reflection of what is going on within the browser. It's timing for resource loading seems to be good but I am not sure that it is acting as a true reflection of exactly what is going on. I've had better luck using HTTP sniffers/proxy applications to monitor the actual HTTP requests coming from the browser. I use Fiddler, but I know there are other tools out there as well.
In short, this many be an issue with the tool and not with how resources are actually being loaded ... at least worth ruling out.
I suppose you're using Firefox 3.0.10 and Firebug 1.3.3 since those are the latest releases.
The Firebug 1.4 beta has done many improvements on the net tab, but it requires Firefox 3.5. If you want to test it in Firefox 3.0, use one of the previous 1.4 alpha versions. But even with the improvements I still struggle to understand the result. I wish the Firebug developers would document more precisely what each part of a download means. It doesn't make sense to me why queuing is after connecting.
My conclusion was not to trust the results in Firebug, and ended up using the WebPageTest. Which was surprisingly good to come from AOL ;-)
Also, what kind of resources are being loaded at the same time as the javascript? Try tracing down the resources that are loaded at the same time, and see if it's referenced in a css/iframe/html-ajax. I'm guessing the reason why nothing else is loaded, is because the browser stops parsing the current HTML when it sees a script tag (without defer). Since it can't continue parsing the HTML, it has nothing more to request.
If you could provide a link to the page you're talking about. It would help everyone to give a more precise answer.
I believe that the content is downloadeded, but not rendered until the JavaScript is finished loading.
This is, from the server's POV, not much of a deal, but to the user it can make a huge difference in speed.
If you think about it a tag has to finish processing before you can continue to render content. What if the tag used document.write or some other wonderfully dumb thing? Until anything within the script tag has finished running the page can't be sure what it's going to display.
Browsers usually have a set number of connections opened to a single domain.
So, if you load all your scripts from the same domain you will usually load them one after the other.
But, if those scripts are loaded from several domains, they will be loaded in parallel.
The reason the browser is blocking during JavaScript downloading is that the browser suspects that there will be DOM nodes created inside the script.
For example, there might be "dcoument.write()" calls inside the script.
A way to hint to the browser that the script does not contain any DOM generation is with the "defer" attribute.
So,
<script src="script.js" type="text/javascript" defer="defer"></script>
should allow the browser to continue parallelizing the requests.
References:
http://www.w3.org/TR/REC-html40/interact/scripts.html#adef-defer
http://www.websiteoptimization.com/speed/tweak/defer/
As others have stated, the script is probably loading other resources through DOM injection.
Script.aculo.us actually loads its child components/scripts itself by doing this -- injecting other <script> tags into the DOM for them.
If you want to see whether or not this is the case, use Firebug's profiler and take a look at what the scripts are doing.
Like others said, one non-blocking way is to inject <script> tags in the page head.
But firefox can also execute loaded <script>s in parallel:
Copy the two lines below:
http://streetpc.free.fr/tmp/test.js
http://streetpc.free.fr/tmp/test2.js
Then go to this page, paste in the input textarea, click "JavaScript", then "Load Scripts" (which builds and adds a <script> child element to the head).
Try that in FF : you'll see "test2 ok", move the dialog box to see "test ok".
In other browsers, you should see "test ok" (with no other dialog behind) then "test2 ok", (except for Safari 4, showing me tes2 before test).
Firefox 3 has introduced connection parallelism feature to improve performance while loading a webpage, I bet this is the source of your problem ;)
When you open a web page that has many
different objects on it, like images,
Javascript files, frames, data feeds,
and so forth, the browser tries to
download several of them at once to
get better performance.
Here's the ZDNET blogpost about it.