Yuki “Piro” Hiroshi 是一个先驱者，也是一个真正的动手实践者。这位来自东京的程序员每当对浏览体验的任何方面感到恼火时，就会为自己构建一个解决方案，并与他人分享。在编写了近 100 个浏览器扩展之后，Piro 最近接受了他迄今为止最大的挑战：将传统的树形标签页 (TST) 扩展迁移到新的 WebExtensions API 和 Firefox Quantum。

传统的 XUL 平台上的 TST 是一个非常复杂的扩展。因此，为新的 WebExtensions API 重建它面临着许多独特的挑战。Piro 遇到了许多障碍和挫折，包括未记录的行为和错误。什么帮助了他？积极的心态和对新 API 功能的敏锐关注。在新的平台环境下工作，Piro 能够完成扩展，并将一个受大众喜爱的扩展带到速度最快的 Firefox 版本中。

想要了解更多技术细节？查看 Piro 的文章 树形标签页的 WebExtensions 迁移故事，了解他的策略、代码片段以及 XUL 和 WebExtensions 平台的架构图。

你的开始

Q: 你为哪个浏览器首次创建了扩展？
我在 Firefox 诞生之前为 Mozilla Application Suite 编写了我的第一个扩展。

Q: 你为 Firefox 创建了哪些扩展？
树形标签页、多个标签页处理程序、文本链接 以及许多其他扩展。我的扩展主要旨在改变 Firefox 的行为，而不是提供全新的功能。

Q: 你为 Firefox 创建了多少个扩展？
我已经为 Firefox 和 Thunderbird 编写了近 100 个扩展。其中大约一半仅供我个人使用。我已经发布了大约 40 个扩展，大多数是传统的 XUL 扩展，其中大部分尚未迁移到 WebExtensions。

Q: 在哪里可以找到你的扩展？
我在 addons.mozilla.org 上发布了我的扩展。你可以在 我的网站 上找到旧的扩展，包括未列出的扩展。

更多关于你的项目

Q: 你为什么要创建扩展？你试图解决什么问题？
我的动机是让浏览网页更轻松。当我遇到任何小的麻烦或不便时，我会创建一个新的扩展作为解决方法。

Q: 你已经从事扩展开发工作多少年了？
十六年。我的第一个扩展于 2001 年 11 月发布。

Q: 在这段时间里技术发生了哪些变化？
Firefox 本身也有一些变化，例如 Gecko 渲染引擎和 JavaScript 引擎的改进。并且出现了新的 Web 标准技术，如 CSS3、ES6 等。最近，我在开发 WebExtensions 时学习了 async-await 语法。这些新技术帮助我清理“脏”或“hacky”代码，并更轻松地维护它。

Q: 你是否将你的扩展从 XUL 迁移到了 WebExtensions？这个过程有多困难？
我将一个大型 XUL 扩展，树形标签页迁移到了 WebExtension。说实话，这非常困难。最困难的部分是功能筛选。由于 WebExtensions API 的限制，某些功能绝对无法迁移。对我来说，做出这些决定很痛苦。

检测我的扩展应该取消并覆盖 Firefox 默认行为的时刻也很难。正如我之前提到的，我的大多数扩展都是为了改变 Firefox 的行为而创建的。但是 WebExtensions API 仅提供有限的入口点，因此我经常不得不根据事件顺序等信息来猜测 Firefox 在任何给定时刻正在发生的事情。

Q: 在实现 Firefox 扩展时，哪些资源对你帮助最大？
为了研究如何在 XUL 中实现扩展，我使用了 DXR，这是一个用于搜索 Mozilla 产品源代码的在线系统。对于 WebExtensions，我查看了其他现有 WebExtensions 和 Google Chrome 扩展的源代码。

Q: 哪些网站或工具帮助你学习 WebExtensions API？
MDN Web 文档 仍然是第一个入口点。此外，我认为链接到现有扩展的源代码将有助于新的扩展作者，就像一个反向词典。

你使用 WebExtensions 的体验

Q: Firefox Quantum 中哪些新技术帮助了你进行迁移？
Mozilla 在 Firefox 57 [Quantum] 中引入了许多新的 WebExtensions API，例如 openerTabId 标签属性。打开者信息对于树形标签页非常重要。如果没有这些 API，树形标签页将无法成功迁移。

Q: 在 1 到 10 的范围内，1 最容易，编写 WebExtensions API 的难度有多大？
总体而言，它在 2 或 3 之间。对于仅向 Firefox 添加新按钮、侧边栏或其他独特功能的扩展，WebExtensions API 足够简单且清晰。但是，在边缘情况下，有一些未记录的行为，它们可能与你正在使用的特定 Firefox 版本密切相关。如果你正在编写改变 Firefox 行为的扩展，你需要深入研究这些未记录的行为。

Q: 现在你已经迁移到 WebExtensions，你喜欢它的哪些方面？
我喜欢 API 的稳定性。通常，WebExtensions API 保证与 Firefox 兼容，现在和将来都是如此。因此，我可以开发长期存在的扩展，而不用担心未来版本中的故障。

Q: 编写这个扩展花了你多长时间？
我于 2017 年 8 月下旬开始开发基于 WebExtensions 的树形标签页版本，并于 2017 年 11 月发布。当然，树管理功能的某些部分是从传统的 XUL 版本导入的，我在 2007 年到 2017 年期间开发了它。

Q: 调试 Firefox 扩展有多难？
如今，这很容易学习。大多数扩展作者不需要成为 Firefox 特定技术的专家，尤其是 XUL 和 XPCOM。此外，Firefox 自身的 about:debugging 功能对于调试扩展非常有用。一个名为 web-ext 的命令行工具对于调试和发布也很有用。

Q: 你的树形标签页扩展的采用情况如何？
大多数人似乎欢迎新的基于 WebExtension 的版本。有些人说，树形标签页是他们使用 Firefox 的主要原因。现在他们很高兴 TST 可以用于 Firefox 57 [Quantum] 和未来的版本。

Q: 在开发扩展时，你遇到了哪些问题？这些问题是如何解决的？
由于 WebExtensions API 仍在积极开发中，我在开发新的树形标签页扩展时，在边缘情况下确实发现了一些错误。我在 Bugzilla 中报告了这些错误。使用 WebExtensions，由于 API 限制导致的问题基本上无法修复。仅在少数情况下可以使用解决方法。因此，向 Bugzilla 报告并等待修复是扩展作者所能做的唯一事情。

但是，从另一个角度来看，这是个好消息。在传统的 XUL 扩展中，作者可以做任何事情，包括替换 Firefox 的内部 XPCOM 组件。因此，扩展的边界和作者的责任可以无限扩大，作者将不得不对来自用户的各种功能请求做出决定：是否要执行它们。这让我很苦恼。但是，使用 WebExtensions，作者只需说，“由于 API 限制，这是不可能的。”我认为这是 WebExtensions 中非常有用和重要的变化。

Q: 你会给其他移植到 WebExtensions 的人什么建议？
尝试简化你的开发任务。如果你想移植一个多功能扩展，请考虑将每个功能放入一个单独的扩展中，而不是尝试将它们全部放入一个扩展中。你可以使用 API 方法让这些扩展彼此交互，这些方法可以是隐式的（基于共享信息，如 tabs.Tab 和 openerTabId 属性）或显式的（基于 runtime.sendMessage() 的自定义消息）。

专注于你想要的结果，而不是担心如何实现它。你可能无法在新版 WebExtensions 中完全复制 XUL 扩展的行为。例如，旧的基于方法的同步（阻塞）API 现在不可用，Firefox UI 上的原始 DOM 事件也不再“可监听”。因此，你需要忘记你以前的操作方式，并学习 WebExtensions 世界中的正常方法。你可能可以找到更好的方法，并获得相同的结果。然后，你将成功地进入新世界，并获得绝佳的体验！

相关内容

树形标签的 WebExtensions 迁移故事
为什么 Firefox 必须杀死你喜欢的扩展
与 Grammarly 的 Sergey Yavnyi 问答
与附加组件开发者 Stefan Van Damme 问答
将 Lightbeam 重制为浏览器扩展
跨浏览器扩展，现已在 Firefox 中提供