错误：访问属性“处理程序”的权限被拒绝答案

【问题标题】：Error: Permission denied to access property 'handler'错误：访问属性“处理程序”的权限被拒绝
【发布时间】：2014-07-13 03:23:44
【问题描述】：

我有一个用于 Firefox 的greasemonkey 脚本，昨天运行良好。我今天尝试使用它（没有修改代码），我注意到它停止工作。经过进一步检查，该脚本现在抛出以下错误：

Error: Permission denied to access property 'handler'

在以下代码块中引发了此错误：

$('body').click(function() {
    // code here
});

当脚本昨天运行良好时，这个错误开始神奇地发生了。我不明白为什么在尝试做一些如此基本的事情（例如在 jQuery 中添加事件处理程序）时会发生此错误。

我的脚本使用的 jQuery 已经在执行脚本的页面中使用，所以我使用这段代码让 GM 可以访问它：

var $ = unsafeWindow.jQuery;

如果需要，作为参考，以下是我在脚本中使用的 Greasemonkey 函数：

// @grant       GM_getResourceText
// @grant       GM_addStyle
// @grant       GM_xmlhttpRequest
// @grant       GM_getResourceURL

我已尝试研究此错误，但找不到任何答案。所有看起来可能有用的问题都涉及 iframe，并且在我的代码或运行它的网站中找不到一个 iframe。我也试过删除并重新安装脚本，但并没有解决问题。

【问题讨论】：

标签： javascript jquery firefox greasemonkey

【解决方案1】：

Greasemonkey 2.0 刚刚被推送到所有设置为自动更新的 Firefox 浏览器。（GM 2 于 2014 年 6 月 17 日发布，但通过审核过程可能需要几周时间。）

Greasemonkey 2.0 radically changed unsafeWindow handling:

向后不兼容更改：

为了稳定性、可靠性和安全性，特权沙箱已更新，以匹配插件 SDK 对 unsafeWindow 的新更改。 要将值写入 unsafeWindow，您需要使用新方法 cloneInto()、exportFunction() 和/或 createObjectIn()。

@grant none 模式现在是默认模式，如果未明确提供，将不再隐含授权。有关详细信息，请参阅帖子 Sandbox API Changes in Greasemonkey 2.0。

通常，要现场访问页面函数或变量，您可以切换到新方法，但在您的情况下，您使用的是var $ = unsafeWindow.jQuery;——这始终是一种不好的做法。

jQuery is a special case 并来回克隆它会破坏事情。
@require jQuery 代替，EG：

// ==UserScript==
// @name        _YOUR_SCRIPT_NAME
// @include     http://YOUR_SERVER.COM/YOUR_PATH/*
// @require     http://ajax.googleapis.com/ajax/libs/jquery/2.1.0/jquery.min.js
// @grant       GM_getResourceText
// @grant       GM_addStyle
// @grant       GM_xmlhttpRequest
// @grant       GM_getResourceURL
// ==/UserScript==
...

【讨论】：

谢谢！ cloneInto() 为我工作。在我的例子中，我试图将一个对象从我的 GM 脚本传递给另一个脚本，当另一个脚本试图访问它时，它抛出了一个权限被拒绝的错误。
MDN 文章：cloneInto、exportFunction、createObjectIn
MDN 链接已损坏，因此只需将其添加为使用嵌套函数 (foo = {bar: function(){..}) 注入对象的快速示例：unsafeWindow.foo = cloneInto({}, unsafeWindow); unsafeWindow.foo["bar"] = exportFunction(function() {}, unsafeWindow.foo);

【解决方案2】：

您正在使用unsafeWindow——正如名称所暗示的那样，使用它并不一定要“安全”——问题可能出在那儿；在 Firefox 中对跨隔间的对象进行了更改：

https://blog.mozilla.org/addons/2014/04/10/changes-to-unsafewindow-for-the-add-on-sdk/

博文中提到了Add-on SDK，但变化是在平台上，所以也会影响Greasemonkey。

所以你基本上尝试从一个隔间（jQuery，来自“unsafeWindow”）中获取一个对象并在你的greasemonkey沙箱中使用。你现在做的方式可能再也行不通了。您可以尝试使用文章中提到的 API，但我担心像 jQuery 这样的整个库可能会有一些问题需要克隆。事实上，最好的方法可能是将 jQuery 也加载到您的 Greasemonkey 隔间中，而不是重用页面中的那个。

这个错误可能是“神奇地”开始的，因为你已经更新了你的 Firefox 版本——或者它得到了自动更新。

【讨论】：

这不是 SDK 更改，是影响 SDK 工作方式的平台更改，实际上文章指出wrappedJSObject 的使用也会受到影响——也就是说，无论 SDK。我知道这一点，因为我所在的团队做出了这种改变。我不太了解通用汽车，但正如所说，这是一个平台变化，通用汽车是建立在它之上的。我不知道他们如何决定处理这样的新限制，但无论是 GM 还是 SDK。
wrappedJSObject docs 没有显示出这样的变化。而 AFAICT，Scriptish 不会以同样的方式受到影响。那篇文章只讨论了 SDK 的变化，它没有提到 Firefox 本身的任何变化——尽管我们知道这 3 个 Components.utils 函数是新的。
另外，需要注意的是：FF 30 并没有破坏这些unsafeWindow 脚本。 GM 2.0 做到了。
如果wrappedJSObject 的文档已经过时，我会和我的队友核实一下。请注意，此更改专门针对具有不同权限的不同隔离专区，例如 SDK 或 GM 等沙盒环境和内容环境。这篇文章的重点是 SDK，因为我们在那里产生了重大影响——GM 不是 Mozilla 的。可能是 Scriptish 与这种情况不匹配。您可以在 Core/XPConnect 下的 Bugzilla 中找到 Firefox 平台的大量更改。同样，这不是 SDK 更改；在我们的案例中，它主要影响 SDK。
你是对的。 FF 的（即将发生的）变化推动了 SDK 的变化，进而推动了 GM 的变化。因此，即使 GM 还没有必要打破常规（或以这种安装基础严重的方式），改变还是会发生。

【解决方案3】：

本页介绍如何在 Greasemonkey 脚本中加载 jQuery：http://wiki.greasespot.net/Third-Party_Libraries