Greasemonkey: WebExtension 兼容性

我一直在思考这个问题。 我没有明确的“决定”，但有几点：

• 我们_刚刚_完成了为 e10s 兼容性而移植的过程。 我们刚开始的时候要困难得多； 例如，Services.ppmm 和 .cpmm 是不错的快捷方式，从一开始就可以很好地依赖它们，但是当我们（负责任地）开始时它们并不存在。
• 这项工作很长而且非常痛苦，我不期待有效地重复它。
• e10s 的推出已经从Firefox 36 （截至 2014 年 9 月）滑到Firefox 42 （截至目前，2015 年 9 月），或者至少九个月。
• 该公告称，仅 Webextensions 至少还需要 1 或 2 年的时间； 它会从现在滑到 2、3、4 年吗？
• 如果我们要这样做，我认为现在是彻底打破并重新架构的合适时机。
  
  
  
  • 我发现自己希望我们半频繁地进行良好的单元测试，即使我们有很多他们永远不会发现的问题，我们也有一些他们会发现的。
  
  
  • 我们终于可以添加Android支持了吗？
  
  
  • 我们实际上不必从头开始重新编写，但是考虑保留哪些代码以及删除哪些代码可能是必要的。
  
  
• 在我们开始另一项如此大的任务之前，我真的很想建立一个更强大的 Greasemonkey/Mozilla 关系。 我对如何实现这一点只有微弱的猜测。
  
  
  
  • 我认为我们今天实际上是移植到像 webextensions 这样的东西的折磨测试； 多年来，我们已经建立了相当多的高级功能。 作为计划一部分的双向沟通​​可能会有很大帮助。
  
  

从设计文档开始将是一个好主意。 本质上，我们需要对所有 Greasemonkey 进行逆向工程，因为它存在于一个好的计划中，而不是一个计划外的有机增长方式，以便所有这些都被结构化。

例如，Services.ppmm 和 .cpmm 是不错的快捷方式，从一开始就可以很好地依赖它们，但是当我们（负责任地）开始时它们并不存在。

我当然不提倡使用 WebExtensions，它们对于像 GM 这样的东西来说是不成熟的

我们实际上不必从头开始重新编写，但是考虑保留哪些代码以及删除哪些代码可能是必要的。

嗯，嗯，我主要是从技术 POV 来看它的。 现在，UI 使用 XUL 覆盖并在共享的 chrome 环境中直接执行脚本。

因此，将事物转换为 HTML 并在独立的窗口上下文中运行每个事物并且仅通过消息传递进行通信似乎是未来应该如何完成的事情。

消息管理器基本上是实现它的最低级别。 更高级别的抽象建立在此之上。 WebChannel.jsm/BroadcastChannel/MessageChannel/WebExtension 频道等。

从设计文档开始将是一个好主意。

GH wiki 是正确的地方吗？ 它是否会发出编辑通知以使协作工作变得简单？

我认为我们最需要一个功能/内部管道列表以及如何以干净的方式实现每个。

如果您对本期主题感兴趣，请阅读：

https://groups.google.com/d/topic/greasemonkey-dev/K6IyDUWnTQc/discussion

谢谢！

相关的：

• https://bugzilla.mozilla.org/show_bug.cgi?id=1271553
• https://bugzilla.mozilla.org/show_bug.cgi?id=1334174

https://developer.mozilla.org/en-US/docs/Web/API/File_and_Directory_Entries_API/Introduction

这是一个超级有趣的 API，但是“这个功能是非标准的，不在标准轨道上”，兼容性非常有限。

我最近在设计功能齐全的 Greasemonkey-under-WebExtensions 方面的所有尝试（参见 #2483、#2484）都令人沮丧。 我开始考虑一种更渐进的开发风格：选择一组更有限的功能并仅支持这些功能。 有点用处，然后希望以后找到更多功能的途径。

检查我的 3.x 安装，我看到（对我而言）每个脚本都是<strong i="6">@grant</strong> none 。 在 27 个中，只有 6 个使用@run-at document-start ，如果不支持，其中大多数至少会稍微优雅地运行。 @require功能被大量使用，而@resource很多。

所以这似乎是一个不错的目标：在<strong i="12">@grant</strong> none模式下支持普通用户脚本，不支持任何GM_ API。 支持@require 。 希望以某种方式支持@resource ，也许效率低下。

（旁注，因为我一直忘记它：计划使用sourceURL使错误更具可读性。看看是否支持多个 sourceURL，或者我们是否必须（我们可以吗？）生成一个 sourceMap，分解@require考虑在内。）

除了 WebExtension API 之外，我们还可以访问普通的 Web API，因此：

https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API

? 对于 WebExtension，IndexedDB 的存储限制是多少？ 这看起来比storage.local好得多。 界面不是最简单的，但它让我们更有能力将脚本彼此隔离并进行选择性读取。 我认为。 文档也不是最容易使用的。

https://github.com/mdn/webextensions-examples/pull/171似乎对 IndexedDB 有有价值的讨论和示例

我取得了一些进展。

https://github.com/arantius/greasemonkey/tree/webbymonkey （位于 88d53b4c67b7825858405eb2591f27c8487ce413）

从头开始重新实现。 签出，转到about:debugging ，按“加载临时加载项”并从根位置选择任何文件。 您可以安装并几乎不运行用户脚本。 绝对没有其他功能。 （嗯，有猴子菜单，但它是一个空的假货，除了看起来不错之外什么也做不了。）即使是这个轻微的功能集，代码周围也散布着许多 TODO。 不能保证其中任何一条是通往更多功能的“正确道路”。

由于旧版本的 Tampermonkey 以及 Violentmonkey 是开源的，所以可以在这里使用其中的一些代码，因为 WebExtensions 类似于 Chromium Extensions？
编辑：实际上，看着它，我不确定与旧的 Tampermonkey 的许可证兼容性。 但是 Violentmonkey 是 MIT 许可的，所以它是兼容的。

@PorygonZRocks ：Violentmonkey 变成 Greasemonkey？

我对编码不是很有经验，但我认为它至少可以有一些关于实现事物的指导方针。 同样，不是很有经验/知识渊博，所以我可能是错的。

值得注意的是，FF56 禁用了所有非多进程兼容插件，因此截止日期可能需要更改。

查看我的dev 分支。 这很粗糙，但功能最低。 这是正在完成的，在这个范围广泛的问题中没有什么要特别跟踪的。

@arantius出于好奇，您是在编写新代码还是重用旧代码？

你需要帮助吗？

再次出于好奇，例如，“parse-meta-line.js”的目的仅仅是将元数据解析为对象吗？

@arantius出于好奇，您是在编写新代码还是重用旧代码？

大多是新的。 在有用的时间/地点复制。 （到目前为止，脚本解析就是一个很大的例子。）

你需要帮助吗？

帮助会很好。 协调起来会很困难。

再次出于好奇，例如，“parse-meta-line.js”的目的仅仅是将元数据解析为对象吗？

其中一行，是的。

其中一行，是的。
我的意思是，除了解析这些之间的元数据之外，它还会做其他事情吗：

// ==UserScript==
....
// ==/UserScript==

如果这是唯一的目标，它似乎有很多代码。

是的，它就是这样做的。 这是生成的代码。 请将此讨论带到https://groups.google.com/d/topic/greasemonkey-dev 。

我不使用 Google 群组 :(
如果是我......我可能会做不同的事情。

谷歌组不存在了。

错误链接： https: //groups.google.com/forum/#!forum/greasemonkey -dev

不完全确定这是否是它的正确位置，但无论如何都在这里。 如果你想让我打开一个单独的问题@arantius ，当然。
4.0.0 不是应该迁移现有脚本吗？ 我更新到 alpha 3（来自最新的非测试版）并注意到我不再有脚本了。

@Phyxion ，如果您安装 3.14，则应迁移脚本。 确保在安装后重新启动浏览器。

之后，当您安装 4.x 时，您应该拥有脚本。 如果您不这样做，那么新问题中的一些详细复制步骤会有所帮助。

Greasemonkey 4 alpha 与 Firefox 57 不兼容。

@erkinalp ，你能详细说明一下吗？ 我一直在使用 4alpha2 进行很多测试和修改，它可以工作，但并非 3.x 中的所有功能都可用。 我还没有拉取 4alpha3 中的更改，所以我不知道该版本的少数提交会破坏什么。

@Sxderp好吧，在我的机器上复制它很容易。 我安装了 3.14 和 10 个用户脚本。 转到 AMO 并下载最新的 alpha。 询问时重新启动。 然后它只是说没有安装用户脚本。 不确定这对复制它有多大用处。

我还没有测试过这个，但我相信 GM4 应该在卸载后丢失它的配置，而 GM3 应该保留它，所以我建议你尝试：

1. 完全卸载 Greasemonkey
2. 重启火狐
3. 安装 Greasemonkey 3.14（包括重启）
4. 重新启动 Firefox 以获得良好的测量
5. 安装 Greasemonkey 4（点任何东西）

这有帮助吗？

我认为顶层 await - 即将所有内容包装在异步函数中 - 不是一个好的设计选择，因为它限制了未来的实现（例如，如果/何时我们取回沙箱或 es-future 领域）。 它使事情与 vanilla JS 执行不一致，其中顶层 await 不可用并且脚本执行......好吧......在顶层。

@阿兰提乌斯
这里还是什么都没有:(
顺便说一句，4.0 应该是这样的： https :
没有按钮或任何东西可以添加脚本。

... 将所有内容包装在一个异步函数中 ...

有了现在可用的东西，我“必须”为了范围目的包装在一个函数中。 我想我相信你没有让它异步的理由。 （至少，在脚本本身中添加一个异步包装函数是微不足道的。）

是的，这主要是关于 async/await，因为目前在 javascript中是

@arantius为什么投反对票？

@arantius评论了2017 年。

... 将所有内容包装在一个异步函数中 ...

有了现在可用的东西，我“必须”为了范围目的包装在一个函数中。 我想我相信你没有让它异步的理由。 （至少，在脚本本身中添加一个异步包装函数是微不足道的。）

尝试删除[mozilla profile]\storage\default\的内容（备份后）
然后再试一次。

说到 UserScript 对象，我不太了解具有三个 UserScript 类的设计决策。 目前他们有一个奇异的继承树，这有点傻。

此外， RemoteUserScript 只使用一次，因此它的创建只是为了获取 id 。 并且 RunnableUserScript 从来没有被直接使用过。

仅供参考...

我在 FF57.0a1 上运行旧插件和 GM 3.13
遗憾的是，我没有收到更新（3.14、3.15），因为它们的最大版本设置为 56。*

虽然可以手动安装..

GM 3.16 仍然在启动时挂起浏览器（我猜它正在更新数据库）