※ 引述《danny0838 (道可道非常道)》之铭言： : Mozilla 近来有四大政策： : http://j.mp/1RiwaPh : 1. 引进 WebExtension API WebExtension API 很不错, 提供这个的话可以让 Chrome 的套件很容易地移殖到 Firefox 上, 但是如果因为提供 WebExtension API 就把既有的套件系统砍到一个 不剩, 反而是本末倒置. : 2. 引进多程序系统 (Electrolysis，简称 e10s) 这个改变只会影响到一部份套件, 不是全部. 套件写法有可能变得比原本复杂, 这 是真的, 因为有一好没两好. 这个不是强制的功能, 使用者仍然可以选择关掉e10s. 如果真的有个套件在 e10s 下无法使用, 而你又非用这个套件不可, 就可以选择关 掉 e10s. 使用 addon sdk 开发是另一个选择, 它处理掉了跟 e10s 有关的问题. 另外, 用 console log 查套件问题是比较阳春的做法, 正常是应该用内建的 debug 工具下断点, 然後直接查看你说的那些无法直接从 console log access 的物件. 参考: https://developer.mozilla.org/en-US/Add-ons/Add-on_Debugger : 3. 套件强制签署 这个是保护使用者的方式, 至於有没有造成开发者问题呢? 我想问题应该不大. 在没这个机制前, 开发者可以写一个套件, 放在自己的下载点, 不用放上 AMO, 使用者装了这个套件, 如果这是一个有问题的套件, Firefox 没有主动撤销这个 套件的能力. 接下来看看有这个签章机制後的情况: 一个套件如果没有在 AMO 上架, 依然可以 自行加上签章(请更新你的 jpm 开发工具, 新版可以自行签章), 然後放在自己的 下载点. 一旦这个套件被回报为有问题的套件, 官方是可以直接撤销这个签章, 防堵有问题的套件再被安装使用. 至於已经在 AMO 上的, 那是经过人工审核的, 有过审议就会自动签. 也就是说, 对原有的开发者来说, 如果你的套件不放上 AMO, 就是多了一个自行 签章的动作而已, 这应该不是什麽大问题. 参考: https://blog.mozilla.org/addons/2015/12/18/signing-firefox-add-ons-with-jpm-sign/ 缩: https://goo.gl/toxzPd : 4. 弃用 XUL 及 XPCOM 这确实是一个大问题, 但我觉得那可能是很久以後的事, Servo 引擎要实用化估计 也可能要再一两年. XUL 是陈旧的包袱, 相对来说, addon sdk 降低了很多开发门 槛. 说真的完全砍掉 XPCOM 的冲击还比砍掉 XUL 大, 几个点我觉得可以再讨论: XUL overlay 作得到, addon sdk 作不到的功能: 我有几个 XUL overlay 套件, 功能最复杂的那一个, 用了很多 XUL overlay 的东 西, 但是这阵子试着移到 addon sdk 上, 还没遇到真的无法搬过去的功能. 你想得 到的介面修改, 应该都还是能用 addon sdk 改出来, 只是这可能会用到低阶 API, 之後需要持续关注相容性问题, 但这些问题, 用 XUL overlay 也一样会遇到. 当然, 还是有可能会有无法移殖的情况, 例如 Firefox UI 层面的大魔改, 只是我 目前还没有遇到, 也许再多移殖几个套件後我就会遇到. 用 addon sdk 开发遇到语系问题: 我好像也遇过, 跟语系档的编码有关, 还有一次是 profile 被我搞坏掉造成多语 系不正常, 你可以参考看看. 没了 XPCOM, addon sdk 还能用吗: 基本上 addon sdk 就是一层介面封装, 所以只要你用 addon sdk 的高阶 API, 基本上不用太担心 XPCOM 问题, 因为介面不动, 只动底层实作是可行的. 也就是说 如果你只用到高阶 API, 就是只用到最上层的介面, 底层的 XPCOM 实作就变成可以 被抽换掉实作而不影响你的套件. 至於低阶 API, 里面当然就有可能用到 XPCOM 或是更多核心元件, XPCOM 被换掉後 确实就有可能不能用, 所以开发者就要多多关心一下相关的核心变动. 但我想这问题就跟你用 addon sdk 开发没啥关系. 回想一下, 传统使用 XUL overlay/XPCOM 的套件一样会有这些随核心变动而 要处理的相容性问题, 不是吗? Addon sdk 只有 Firefox 能用: 这可能是个问题, 不过如果是其他社群版的 Firefox, 只要 Gecko 核心版号有跟上 官方 Firefox, 应该就没问题, 之前有 Pale Moon 使用者来跟我反映套件相容性 问题, 我才发现 Pale Moon 的核心停在很旧的一版 Gecko, 不知道现在是不是还是 这样. 如果是的话, 就有可能不能支援. cfx 被弃用: 其实 cfx 就只是一个工具, 帮你处理初始化套件, 打包套件这些琐碎的工作, 你可以想成本来你用记事本写 code, 现在改用 sublime. 我觉得这没有什麽问题. 套件不给力的 Firefox 和 Chrome/Chromium二创 还有啥不同: 本质上的不同, Firefox 带给了使用者选择的机会, 一个不被 Chrome (来自 Google — 全球最大的广告公司) 控制的机会, 使用者有了选择, 选择 Chrome 或是 Firefox 取决於你自己, 而不是像回到 IE 垄断的年代, 使用者没有选择. Android 上的 Chrome 为什麽没有套件, 因为类 adb 的套件就是这个最大的广告 公司最不想看到的. 向 Firefox 团队反映意见: 开发者的反馈我想还是非常重要的, 如果真的遇到开发上的限制, 可以提出讨论, 我想不至於搞到最後变成因为限制而无法写出重要的功能啦, 至少目前还不是这样. 想持续关注 Mozilla 的相关议题, 可以来 MozTW 的聊天群组, 当然也会有套件 开发的讨论. 可以交流一些使用和开发上遇到的问题. --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 1.160.11.21 ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Browsers/M.1458706661.A.C8C.html ※ 编辑: ettoolong (1.160.11.21), 03/23/2016 12:21:41 你说的没错, 但是同样是 Blink 核心这点, 就可以想成这个核心的市占率. 你可以想像, 如果市面上只剩 Blink 核心, 以後 web 的标准是不是可以 Google 说了算? iOS 坚持不开放其他核心的一个原因就是, 只要 iPhone 卖得还不错的一天, Apple 就可 以保证 webkit 核心在行动平台上有一定的占有率, Apple 对行动平台上的 web 相关标 准制定就可以有一定的话语权(简单说就是说话比较大声啦). 开放 Chromium 对 Google 最大的好处就是实质提高了 Blink 核心的市占率, 因此 Google 就可以说话大声一点. 如果变成一个核心独大, Google 会不会制定对他们 有利的标准? 反正 Google 说了算. 使用 Chromium 再改造的浏览器当然可以作出 Google 不提供给使用者的东西, 但也别 忘了, 真正的核心 Blink 还是在 Google 手里. 这才是 Google 参与制定 web 标准的 最大本钱. 我不是叫大家不要用 Blink 核心, 我想说的是 选择的自由 对使用者的重要性. ※ 编辑: ettoolong (1.160.11.21), 03/23/2016 14:48:18