※ 引述《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 的聊天群组, 当然也会有套件
开发的讨论. 可以交流一些使用和开发上遇到的问题.