XUL 的 Javascript 在什么上下文中执行?

发布于 2024-08-09 10:11:10 字数 221 浏览 6 评论 0原文

您为 XUL 组件编写的 javascript 是否可以与网页中定义的 javascript 进行交互?

例如,如果特定网页具有 dooSomethingNeat() 函数,我可以在 XUL 覆盖中定义一个按钮来执行该函数吗?或者它是否位于另一个命名空间中?

换句话说:如果我想通过自己的代码增强网站的功能,那么编写 Firefox 扩展或使用 Greasemonkey 之类的东西是否更有意义?

Is it possible for the javascript you write for a XUL component to interact with the javascript defined in a webpage?

Eg, if a particular webpage has a dooSomethingNeat() function, can I have a button defined in a XUL overlay execute that function, or does it live in another namespace?

Put another way: if I'm looking to enhance the functionality of a website via my own code, does it make more sense to write a Firefox extension or use something like greasemonkey?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

晨曦慕雪 2024-08-16 10:11:10

请参阅我对另一个问题的回答在这里

  • 网页代码确实位于与浏览器代码执行范围分开的“命名空间”中。
  • 但这并不意味着您无法从扩展程序访问它。
  • 另一方面,目前在内容页面中安全地运行功能并不容易。
  • Greasemonkey 脚本(以及普遍存在的脚本,也可以与网页交互)比扩展更容易开发,并且 Greasemonkey 已经实现了所需的安全预防措施,以允许您安全地与网页交互。
  • 如果您希望其他人使用您的脚本,将其打包为独立扩展可以降低进入门槛(在另一种情况下,现有 GM 用户可能更喜欢更简单的 GM 脚本而不是单独的扩展)。

因此,如果您可以使用 GM 脚本或普遍存在的脚本来实现您需要执行的操作,我会建议您使用它。至少你可以从它开始,然后当你发现 GM 无法做到的事情时转换为扩展。

如果您需要 Greasemonkey 不支持的功能,或者您只是想尝试创建扩展,那么它也是一个可行的选择。

See my answer to another question here.

  • The webpage code does live in a 'namespace' separate from the scopes the browser code executes in.
  • It doesn't mean you can't access it from an extension, though.
  • On the other hand, running a function in a content page is not very easy to do securely at this moment.
  • Greasemonkey scripts (and ubiquity scripts, which can also interact with web pages) are somewhat easier to develop than extensions, and Greasemonkey already implements the required security precautions to allow you interact with web pages safely.
  • If you want others to use your script, packaging it as a standalone extension lowers the barrier to entry (on the other case, existing GM users may prefer simpler GM scripts to a separate extension).

So if you can implement what you need to do with a GM script or an ubiquity script, I'd say go with it. At least you can start with it, then convert to an extension when you find something you can't do with GM.

If you need features not supported by Greasemonkey or if you just want to try creating an extension, it is also a viable option.

指尖微凉心微凉 2024-08-16 10:11:10

有一个 Greasemonkey-to-firefox-extension “编译器”可用,但它不是不了解最新的 GM 变更。

但是,它确实具有用于页面交互和安全性的基本 GM 框架,所有这些框架都包装为独立扩展,可供您修改和扩展。

是否使用独立扩展或 GM 脚本取决于谁将安装它。用户群愿意先安装 GreaseMonkey,然后再安装脚本吗?或者仅扩展就足以构成安装障碍吗?

我相信,GM 许可证确实允许使用预设脚本重新打包它,但目前我找不到对此的引用。

There is a Greasemonkey-to-firefox-extension "compiler" available, but it isn't up-to-date with the latest GM changes.

However, it does have the basic GM framework for page interaction and security all wrapped up as a standalone extension, ready for you to modify and extend.

Wether to use standalone extension or GM-script depends upon who will be installing this. Will the user-base be willing to install GreaseMonkey, THEN the script? Or is the extension alone enough of an installation barrier?

The GM license does allow for repackaging it with pre-set scripts, I believe, but I can't find back citations for this, at the moment.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文