Question

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 ?

Answer 1

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:

1. Runs scripts in an XPCNativeWrapper sandbox, unless @grant none is in effect (as of GM 1.0).
2. Wraps the script in an anonymous function by default.
3. 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:

1. Runs scripts in an “isolated world”.
2. Wraps the script in an anonymous function.
3. 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:

1. The only way for non-Tampermonkey userscripts to access objects or functions provided by the target page.
2. Almost always fully compatible between Chrome, Firefox, Opera, etc. (IE is, as always, something else.)
3. Often easier to debug the whole script; developer tools work normally.

Injection drawbacks:

1. 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.

2. Can cause side effects or conflicts with the page’s JS.

3. 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.

4. The page can see, use, change, or block the script.

5. 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.