Why is window (and unsafeWindow) not the same from a userscript as from a <script> tag?
greasemonkey, javascript, scope, userscripts
Solution
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.
Problem
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 ?