※ 引述《ettoolong (ettoolong)》之銘言：
有神，先膜拜 m(_ _)m
: : 1. 引進 WebExtension API
: WebExtension API 很不錯, 提供這個的話可以讓 Chrome 的套件很容易地移殖到
: Firefox 上, 但是如果因為提供 WebExtension API 就把既有的套件系統砍到一個
: 不剩, 反而是本末倒置.
同意
: : 2. 引進多程序系統 (Electrolysis，簡稱 e10s)
: 這個改變只會影響到一部份套件, 不是全部. 套件寫法有可能變得比原本複雜, 這
: 是真的, 因為有一好沒兩好. 這個不是強制的功能, 使用者仍然可以選擇關掉e10s.
我有點懷疑...按 Mozilla 最近的作風，
天曉得會不會在幾個版本後強制多程序，單程序成為絕響？
希望不會發生
: : 3. 套件強制簽署
: 也就是說, 對原有的開發者來說, 如果你的套件不放上 AMO, 就是多了一個自行
: 簽章的動作而已, 這應該不是什麼大問題.
我之前的確不清楚有這樣的機制，感謝提供情報。
但這還是有問題，因為所有的套件仍然需要被 AMO 審核才能安裝。
就開發者的角度而言，自行簽章看起來很簡單，但簽章一定會過嗎？
不一定，你得符合 AMO 制定的規範，
如果程式碼有違反規範的 pattern，會被擋死無法簽章；
如果程式碼有疑似違反規範的 pattern，會被強制人工審核，那就可能拖很久。
可能有人說，不要違反規範不就好了嗎？
問題是什麼是違反規範？那是 AMO 說了算，
而且自動驗證程式是很笨的，沒有多特別的程式碼也可能被找麻煩，
比如我以前有段程式碼：
setTimeout(someFunction, 0);
這段程式碼就被自動驗證程式挑毛病，AMO 還寄信來要我改，
理由是 setTimeout 第一個參數必須放 function（而不能放 string），
是人都看得出來，我的 someFunction 顯然是指向一個固定的 function，
但自動驗證程式可沒那麼聰明，
而那位寄信過來的審核者其實可以自己檢查，但他沒有，先要求我改再說。
對，我是可以把它改成：
setTimeout(function () { someFunction() }, 0);
但我就是不爽本來可以直接調用的函數被要求改成間接且低效能的寫法！
這段程式碼跑一次還好，如果是放迴圈裡跑幾千次呢？
還有，setTimeout 第一個參數放上來源不明的 string 是有安全疑慮，
但假使那個 string 顯然安全，AMO 會放行嗎？
其他還有像：
document.createElement(aNodeNameString); // 只能用靜態字串
aNode.innerHTML = "Some <em>emphasize text</em>."; // 請改用 DOM API
aNode.innerHTML = ""; // 請改用 DOM API
這些都會被自動驗證程式擋下來，然後被 AMO 找上門，
我後來和他們說明過，他們是沒再強迫我改，但中間還是被拖了很久。
雖然那不是發生在自動簽署，但未來你要自動簽署時，
難保不會因此被搞成曠日費時的人工審核...
就使用者的角度而言，
他們會因此失去了像這樣的選擇：
穩定版本的 Firefox +
99% AMO 簽署過的套件 +
1% 自行開發供特殊用途的"不安全"套件
我知道我可以使用 Nightly 等版本，
但我為什麼要為了安裝極少數我需要的功能而被迫使用非穩定的 Firefox 版本？
說到底，一個套件能不能安裝必須由 AMO 決定，是件很奇怪的事，
也違反開源、自由的精神，
雖然這還不算我完全不能接受的事，
但我認為套件未簽署時只警示而不強制拒絕安裝會比較合理。
: : 4. 棄用 XUL 及 XPCOM
: XUL overlay 作得到, addon sdk 作不到的功能:
: 我有幾個 XUL overlay 套件, 功能最複雜的那一個, 用了很多 XUL overlay 的東
: 西, 但是這陣子試著移到 addon sdk 上, 還沒遇到真的無法搬過去的功能. 你想得
: 到的介面修改, 應該都還是能用 addon sdk 改出來, 只是這可能會用到低階 API,
: 之後需要持續關注相容性問題, 但這些問題, 用 XUL overlay 也一樣會遇到.
: 當然, 還是有可能會有無法移殖的情況, 例如 Firefox UI 層面的大魔改, 只是我
: 目前還沒有遇到, 也許再多移殖幾個套件後我就會遇到.
XUL overlay 的確不是非有不可，
從以前的 bootstrap 開始，就可以直接用修改元素的方式改變 XUL 了，
而 addon SDK 如果可以使用 require("chrome") 之類的方式，
那就絕對有像 bootstrap 套件一樣做到所有 XUL overlay 能做的。
吹毛求疵地說，唯一不能做到的大概是「套件更動時必須重新啟動」，
UI 大魔改本身不困難，也不是非 XUL overlay 不可，
麻煩的是套件卸載時怎麼改回來，
照說重啟 Firefox 是最簡單的做法，
但 bootstrap 或 SDK 這種免重啟的套件會要求開發者把卸載功能寫出來，
有時這會很折騰，麻煩到讓人寧可放棄免重啟，
BUT...你沒有這種選擇哦XDD
: 用 addon sdk 開發遇到語系問題:
: 我好像也遇過, 跟語系檔的編碼有關, 還有一次是 profile 被我搞壞掉造成多語
: 系不正常, 你可以參考看看.
我記得之前確認過語系檔編碼是 UTF-8 no DOM，但還是不行；
但現在再試一次又正常了，或許是我之前搞錯了什麼@@
總之現在沒事了XD
: 沒了 XPCOM, addon sdk 還能用嗎:
: 基本上 addon sdk 就是一層介面封裝, 所以只要你用 addon sdk 的高階 API,
: 基本上不用太擔心 XPCOM 問題, 因為介面不動, 只動底層實作是可行的. 也就是說
: 如果你只用到高階 API, 就是只用到最上層的介面, 底層的 XPCOM 實作就變成可以
: 被抽換掉實作而不影響你的套件.
: 至於低階 API, 裡面當然就有可能用到 XPCOM 或是更多核心元件, XPCOM 被換掉後
: 確實就有可能不能用, 所以開發者就要多多關心一下相關的核心變動.
: 但我想這問題就跟你用 addon sdk 開發沒啥關係.
: 回想一下, 傳統使用 XUL overlay/XPCOM 的套件一樣會有這些隨核心變動而
: 要處理的相容性問題, 不是嗎?
我覺得這問題的重點在於，如果拿掉 XPCOM，會不會用不同形式提供相同的功能，
還是拿掉了就是開發者再也沒那功能可用。
: Addon sdk 只有 Firefox 能用:
: 這可能是個問題, 不過如果是其他社群版的 Firefox, 只要 Gecko 核心版號有跟上
: 官方 Firefox, 應該就沒問題, 之前有 Pale Moon 使用者來跟我反映套件相容性
: 問題, 我才發現 Pale Moon 的核心停在很舊的一版 Gecko, 不知道現在是不是還是
: 這樣. 如果是的話, 就有可能不能支援.
大大您可能忘了不只是 Firefox only，而是 Firefox >= 38.0 only
以往無論核心 API 怎麼改，甚至是從 XUL overlay 改 bootstrap，
開發者都總是可以寫些判斷條件讓整個套件向下相容。
但只要用 Addon SDK 寫，打包出來就是無法支援 Firefox < 38.0，
那我以前寫的能支援 Firefox 2.0~45.0 的套件要怎麼辦？
不改 Addon SDK，就是隨著 XUL/XPCOM 棄用而有天不能支援 Firefox > x，
改成 Addon SDK，就是跟 Firefox < 38.0 的使用者說再見。
這麼粗暴的拒絕相容，真的是第一次看到，這是我最不爽的地方。
我現在還是很苦惱，要不要轉移到 Addon SDK 然後放棄舊版 Firefox 的使用者。
: cfx 被棄用:
: 其實 cfx 就只是一個工具, 幫你處理初始化套件, 打包套件這些瑣碎的工作,
: 你可以想成本來你用記事本寫 code, 現在改用 sublime. 我覺得這沒有什麼問題.
用記事本和 zip 就能寫套件和只能用 node.js + jpm 寫套件，自由度是不太一樣的，
如果有一天 node.js + jpm 被砍掉，換成另一個我可能懶得學的平台，
我不知道屆時我還能不能接受。
這不算很嚴重的問題，只是吹毛求疵一下而已。
: 套件不給力的 Firefox 和 Chrome/Chromium二創 還有啥不同:
: 本質上的不同, Firefox 帶給了使用者選擇的機會,
: 一個不被 Chrome (來自 Google — 全球最大的廣告公司) 控制的機會,
: 使用者有了選擇, 選擇 Chrome 或是 Firefox 取決於你自己,
: 而不是像回到 IE 壟斷的年代, 使用者沒有選擇.
同意，另外我想補充一點，
現在還在用 Firefox 的使用者，
我想大多是因為只有 Firefox 提供了某些 GC 不提供的功能，
換言之，只要未來 Firefox 套件系統仍能提供 Chrome/Chromium 不提供的功能，
就還是會有一定的市場，
如果 GC 是 30 分的自由度，
新 Firefox 和舊 Firefox 的差別可能是：
80 分自由度/功能性 + 可用 GC 套件 + 開發容易
與
100 分自由度/功能性 + 不能用 GC 套件 + 開發很麻煩
那個比較好，說實話滿難下結論的，我覺得還要觀望。
: Android 上的 Chrome 為什麼沒有套件, 因為類 adb 的套件就是這個最大的廣告
: 公司最不想看到的.
精闢XDD
: 向 Firefox 團隊反映意見:
: 開發者的反饋我想還是非常重要的, 如果真的遇到開發上的限制, 可以提出討論,
: 我想不至於搞到最後變成因為限制而無法寫出重要的功能啦, 至少目前還不是這樣.
Mozilla 在 WebExtension 還很草創時就放話要砍 XUL/XPCOM，
確實會讓很多開發者緊張起來。
希望未來 WebExtension 確實可以改善到保有和現在 XPCOM 差不多強大的功能，
也希望現在放棄的開發者屆時還願意回來繼續開發。
: 想持續關注 Mozilla 的相關議題, 可以來 MozTW 的聊天群組, 當然也會有套件
: 開發的討論. 可以交流一些使用和開發上遇到的問題.
是指 irc channel 嗎？我每次都找不到人XDD