为什么来自userscript的窗口(和unsafeWindow)与来自<script>标记的不一样？

Question

在开发这个小用户脚本时，我遇到了一个问题。当我想用我的脚本阻止所有运行中的XMLHttpRequest的时候，什么都没发生(至少在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();

用window替换unsafeWindow时也是一样的。

然而，当我使用这个小把戏时，一切都像一种魅力：

// No more call to main(), and:
var script = document.createElement("script");
script.textContent = "(" + main.toString() + ")();";
document.body.appendChild(script);

对xhr.open的每次调用都由我的自定义函数取代，不再使用AJAX。

因此，我猜window元素在脚本内部调用main时与从<script></script>容器调用时不一样。有人能解释一下为什么吗？

Answer 1

见“Chrome用户脚本是否与全局名称空间分离，如Greasemonkey脚本？”。Chrome用户脚本/内容脚本和Greasemonkey脚本都从页面的javascript中分离出来。这是为了防止你被黑，但它也减少冲突和意外的副作用。

但是，每个浏览器的方法是不同的。

火狐：

1. 在一个XPCNativeWrapper沙箱中运行脚本，除非@grant none生效(从GM1.0开始)。
2. 默认情况下将脚本包装在匿名函数中。
3. 提供unsafeWindow来访问目标页面的javascript。但是请注意，敌对的网站管理员可能会跟踪unsafeWindow的使用，回到脚本的上下文中，从而获得更高的特权来攻击您。

Chrome:

1. 在一个“孤立的世界”中运行脚本。
2. 将脚本包装在一个匿名函数中。
3. 严格地阻止脚本对页面JS的任何访问，反之亦然。 最近版本的Chrome现在提供了一个名为unsafeWindow的对象，其兼容性非常有限，但该对象不提供对目标页面JS的任何访问。它与脚本作用域中的window相同(在页面作用域中不是window )。

也就是说，如果正确实现的话，使用unsafeWindow的脚本版本应该可以在火狐中工作。在Chrome上使用坦佩猴子的延伸可能有效，但我现在不打算再检查一遍。

当您执行“技巧”(var script = document.createElement("script"); ...)时，您是将代码注入目标页面。这绕过了沙箱，是普通Chrome用户脚本上与页面的JS交互的唯一方法。

注入优势：

1. 非Tamper猴子用户脚本访问目标页面提供的对象或函数的唯一方法。
2. 几乎总是完全兼容Chrome，Firefox，Opera等。
3. 调试整个脚本通常更容易；开发人员工具正常工作。

注入缺陷：

1. 脚本(至少是注入的部分)不能使用GM_函数--特别是GM_xmlhttpRequest() --提供的增强特权(特别是跨域权限)。 请注意，目前Chrome完全、本地只支持GM_addStyle、GM_xmlhttpRequest、GM_log和GM_openInTab。 然而，Tamper猴子几乎完全支持GM_函数。
2. 可能导致副作用或与页面的JS冲突。
3. 使用外部库会带来更多的冲突和时间问题。它远没有@require那么简单。 @require还通过本地副本运行外部JS --加速执行，并且几乎消除了对外部服务器的依赖。
4. 页面可以看到、使用、更改或阻止脚本。
5. 需要启用JS。火狐Greasemonkey，特别是，可以运行在一个被JS阻塞的页面上。这在臃肿、拙劣和/或侵入性页面上可能是天赐之物。