|
阅读：1903回复：9
翻译：WebExtensions 常见问题解答
听说你们没听取社区的意见就做了决定，为什么？
WebExtensions 还处于起步阶段，我们一开始会采用一系列 Chrome 常用的 API 以便用户能顺利使用。我们不想完全复制 Chrome，我们要在带给 Firefox 多进程和其他新特性的同时确保差异性。这项改革需要得到社区的意见和协助，对此我们一直以来也在积极寻求。WebExtensions 将在未来的数周、数月和数年内不断改进，期间我们希望开发者社区能扮演一个重要的角色。 为什么需要做如此大的改变？ 我们相信从 Firefox 移除 XUL 和 XPCOM 是一项长期的战略需要。这些技术已存在 15 年之久且没有其他浏览器使用它们。我们再继续投入已然没什么意义，但性能和安全性还得依赖它们。 然而，在找到附加组件改进方式之前我们还不能开始移除 Firefox 里的这些技术。我们宣布将尽早使用 WebExtensions 并淘汰这些技术也是为了期间能听取社区的反馈。我们知道 WebExtensions 需要不断改进，也知道 XUL 还会以某种形式存在一段时间。 听起来你们在复制 Google... Chrome 扩展的 API 设计时就在进程分离的模式下运行良好，我们也从中获得了一些灵感，也会复制一部分有用的功能。但是会有一些差别，WebExtensions 不是要复制 Chrome 或让 Chrome 扩展不经修改就直接运行在 Firefox，而是为了通过提供常用的 method 和 interface 来简化跨浏览器的开发。我们不会实现所有 Chrome 的 API，而 Chrome 貌似也不会实现我们添加的一部分 API。你可以把这些 API 想成一个维恩图，中间是用于内容脚本（content scripts）、标签页和窗口的跨浏览器 API，在 Firefox 这一侧的是用于工具栏和其他 UI 元素的 API，在 Chrome 一侧的是用于 Google 云服务的 API。 如果你们要扩充 Google 的 API，WebExtensions 要如何实现跨浏览器？ 与作为网页平台不同，我们不希望每个浏览器都用同一方式实现 WebExtensions 的方方面面。但即使浏览器之间并非完美兼容，使用一个常用 API 对扩展开发者来说仍然有很多好处。如果开发者使用常用 API，那他们的扩展只需要极少（甚至不需要）的改动就可以运行在不同浏览器上。即使开发者使用了浏览器专属的 API，他们的扩展也还可以通过特性检测和后退机制运行在其他浏览器上。举例来说，一个使用工具栏 API 的扩展或许可以后退到其他浏览器所使用的浏览器动作（browser action） API。 为什么要用 WebExtensions 而不是 Jetpack？ 我们选择集中注意力开发 WebExtensions API 的原因有很多。首先，Chrome 的扩展比 Jetpack 附加组件要来的多，那就会有更多对 WebExtensions 熟悉的开发者。WebExtensions 内建了对内容阻挡（content blocking）的支持，而这项功能已为许多流行的广告过滤和反跟踪扩展所用，但 Jetpack 缺少这样的 API。Jetpack 也无法解决附加组件开发者必须为每个浏览器维护一套不同代码库的问题。一开始就基于 Chrome 的 API 来实现 WebExtensions 意味着那些坚持使用常用 API 的开发者可以在一套常用代码库上工作并轻松将扩展移植到不同浏览器。 从 Jetpack 的优势来看，它有一个类似于 node.js 的强大的模块系统。但考虑到 JavaScript 很快会内建对模块的支持，这个优势也不会保持太久。 在淘汰 XUL/XPCOM 以后哪些附加组件会无法使用？ 很多附加组件都得更新，我们估计在转换到新 API 的过程中有部分会无法使用。存在的风险还包括一部分停止维护或维护者没时间移植的附加组件将无法成功转换。 我们不想限制附加组件可在 Firefox 实现的功能。我们会和每位有兴趣的开发者合作将他们的附加组件成功运行在 Firefox，并尽可能提供更多在不同场景所要用到的功能。这种方式就为了让开发者能更容易扩充 Firefox 的功能，而不会像现有 XUL/XPCOM 系统那样脆弱，也是为了让 Firefox 本身更容易脱离 XUL/XPCOM。 我此时在编写一个新扩展，我该用哪个 API？ 这是一个复杂的决定。如果你编写过 Chrome 的扩展，那最好是等到 WebExtension 可以作为日常使用以后再写，我们希望是再等上几个月。你可以查阅 WebExtensions wiki 了解你所用到的 API 是否已被支持或未来是否可能被支持。 如果你正计划编写一个全新的 Firefox 专属的扩展，在 WebExtensions 成熟以前你最好是使用 add-on SDK (Jetpack)。Jetpack 可以很好地支持老版本 Firefox 并且文档完善。但你最好是阅读一下 "Firefox 多进程及其 SDK" 确保你的附加组件兼容 Electrolysis。 这会对一些开发上的试验产生限制吗？ 如果 WebExtensions 最终限制在使用 Chrome 模块上，那会的。但实际上我们正在为扩展作者设计一套更具有灵活性的系统，可以实现当前 WebExtensions API 所不支持的新特性。关于这方面的一些讨论也已经开始了，目的是推动附加组件作者在已知 Firefox 正式版发布时不保证兼容性的情况下对这个机制进行试验，以及罗列出 WebExtension API 稳定版未来所要添加的特性。 为什么在这时候淘汰 XUL？Firefox 还在内部使用它啊。 是的，Firefox 现在还在内部使用它。但 Firefox 也一直积极计划着从内部移除 XUL。伴随着 Firefox 逐渐移除 XUL 的过程，使用 XUL 的附加组件也会变得支离破碎（也就是在每次发布新版本时无法正常使用）。 为什么要保留 .xpi 打包的格式？ 我们是使用 JAR 来为 WebExtensions 签名，而 Chrome 使用的则是另一套不同的系统。通常签名是浏览器专属的功能，要整合两个签名系统会很困难，维护 Firefox 现有用于打包的扩展名也有意义。而 WebExtensions 所用到的也只是 XPI 文件格式的后缀名本身而已，在听取更多反馈以后我们也有可能对现有的文件扩展名做出改变。 恶意附加组件会真的成为一个问题吗？ 是的，请看看这个"关于扩展签名的实例"。 翻译自 mozilla wiki：https://wiki.mozilla.org/WebExtensions/FAQ |
|
|
|
1楼#
发布于：2015-08-27 21:49
很好奇以后火狐的 UI 会用什么。
|
|
|
|
2楼#
发布于：2015-08-27 22:01
时间会给我答案
|
|
|
3楼#
发布于：2015-08-28 09:04
userChromeJS 扩展能用WebExtensions重新开发吗？？我很看重这个。。。
|
|
|
4楼#
发布于：2015-08-28 10:57
linhaicong168：userChromeJS 扩展能用WebExtensions重新开发吗？？我很看重这个。。。回到原帖这个恐怕很难。。。。 |
|
|
|
5楼#
发布于：2015-08-28 11:28
|
|
|
6楼#
发布于：2015-08-28 17:16
放弃xul是不是能提高点firefox的启动速度
|
|
|
7楼#
发布于：2015-08-28 18:51
|
|
|
|
8楼#
发布于：2015-08-28 20:45
唉 感觉在跟着chrome走，弧形标签、webextension
放弃gecko的日子是不是也快提上日程了…… |
|
|
9楼#
发布于：2015-08-29 17:01
|
|
|
