※ 引述《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 的聊天群組, 當然也會有套件
開發的討論. 可以交流一些使用和開發上遇到的問題.