Firefox 57 毀掉分頁群組之後怎麼辦

眾所周知，預計 2017 年 11 月釋出的 Firefox 57 將移除所有舊版附加元件（使用 XUL/XPCOM/Addon SDK 的附加元件）的支援，只支援 WebExtensions 的附加元件。

如此重大的修改將會讓我失去 Firefox 對我來說最重要的分頁群組功能，原本分頁群組功能的開發者 Quicksaver 已經表示不會將原本的 Tab-Groups 插件移植到 WebExtensions API ，等於是宣判了這插件的死刑。

除了分頁群組之外，過去所有使用者熱愛的附加元件都將停止運作，各大討論版上面使用者哀嚎四起，還有 change.org 的連署，可惜沒過。

Mozilla 這個決定蠢斃了：

• 大部分的使用者不使用附加元件沒錯，但不支援 XUL 附加元件會讓一大群 power user 和死忠粉絲背棄
• 畢竟 Firefox 雖然比 Chrome 慢，但也只有 Firefox 可以讓你客製化到都認不出來，像我使用的 Firefox-on-OS-X Label 附加元件。 Chrome 你要做這 API ？還要先重新定義一個 Javascript 的界面、新增 API Permission 、一堆重複的工。Firefox？登登！Components.interfaces.nsIMacDockSupport ！附加元件直接 tap into 原本就是負責處理這東西的內部界面，不需要重新定義界面巴拉巴拉。附加元件 15 行寫完收工。

好吧抱怨就此結束 :-p 我比較喜歡 Firefox 這樣可以自己自由 mod 的舊架構，而不是開發者爽開給你 API 才能 mod 的新架構。

身為一個分頁群組難民兼任自己要的功能自己寫的開發者，當然想要調查一下有什麼可行的解決方案可以拯救分頁群組功能，我整理出這些方法：

1. build 自己的 firefox fork ，把 legacy extension 直接包進去讓它可以用 legacy API

這會有點麻煩，每次釋出新版的時候要自己 patch 加入想要的 extension ，每個人想要的 extension 可能也不一樣，但這是保留原汁原味 legacy extension 唯二的方法。

挖了一下 Firefox 的 source code，原本內建在 Firefox 的 Panorama （就是分頁群組功能）在 codebase 裡面的這裡（應該是啦我有點不確定）：mozilla-esr38/browser/components/tabview ，後來 tabview 被獨立出去成為 tabgroups extension ，所以理論上我只要把這個過程逆向操作，我就可以把現有的 extension 包回去 firefox 。但這 code structure 跟後來獨立出來成為 extension 的 tabgroups 長相實在差有點多，讓我有點搞不清楚到底當時是怎麼整理 codebase 獨立成 extension 的，這還需要更仔細的研究。

這麼做也有極限，因為 legacy API 和 extension 都不會再被維護，所以如果有新的 codebase 影響 legacy API 的運作，也不會被修正，legacy extension 也不會為了 broken API 去 workaround ，所以在更久的未來可能終究無法正常使用。

2. 啟動 legacy API 相容設定

猜測在 57 應該會有個 about:config 設定值可以允許 legacy extension 被安裝並且使用 legacy API 才是，雖然我還沒仔細去看這個設定值在哪裡。（等我找到再來更新這一段）

這個和方法1也有一樣的問題， legacy API 和 extension 都不會再被維護。

3. 使用 denschub/firefox-tabgroups

這個 extension 本來是 tabgroups 的替代方案，也使用 legacy API, 但是和 tabgroups 不一樣的地方是作者 denschub 承諾說會支援新的 firefox ，雖然怎麼做、會有什麼功能他沒有說，但勢必一樣得受限於新的 WebExtensions API 。

4. 使用 contextualIdentities API 的相關插件

Firefox 前陣子新推出了一個 containers testpilot，基本上的概念是「在 Firefox 中透過不同容器來管理不同的線上身分，不論是線上購物、規劃旅遊行程、工作使用，更可以建立其他不同色彩與名稱的自訂容器。每個容器當中的 Cookie 會分開儲存」，它的目標使用情境看起來和分頁群組有些相關，因為分頁群組確實偶爾會被拿來這樣使用，但又有相當不同，containers testpilot 原本不是設計給「分頁管理」的情境下來使用的，所以沒有提供「顯示/隱藏」特定分頁的 API 。

有人去 containers 的 github 開了一個 issue 說，可不可以接受 containers 作為分頁管理工具的用途，獲得超多回應，畢竟現在這看起來是最有希望帶回分頁群組功能的道路了。

基於 contextualIdentities API  的插件目前有 eoger/tabcenter-redux 和 jonathanKingston/sea-containers ，這兩個是一開始就以 WebExtensions API 開發的插件，另外未來 denschub/firefox-tabgroups 應該也會使用這個 contextualIdentities API 。

contextualIdentities API 的問題

我去看過 contextualIdentities API 之後就覺得這真是個噁心霸道的東西，在棄用 legacy API 之後，插件沒辦法直接修改到 Firefox 的內部，所以照理來說 containers testpilot 是做不出來的，因為原本根本就沒有這種 WebExtensions API ——結果！ Firefox 團隊就這樣直接幫 containers testpilot 開了後門，量身打造了一個 API 給他們——就是 contextualIdentities API 。

覺得很噁心，這不就剛好證明了能夠作出重大有意義的功能靠現有的 WebExtension API 根本做不到嗎？以前可以自己直接用 XPCOM ，現在還要先跟 Mozilla 開發團隊搞好關係才能在 core 塞進自己的插件需要的 WebExtensions API 。

撇開這個不說，這個 API 的設計看來也是一個 monolithic piece of poorly designed code 。正常來說 API 的設計應該是先暴露出最基礎的核心功能，然後由開發者自己組裝核心功能調用來作出有意義的插件吧？結果 contextualIdentities 這個 API 裡面直接把幾個在這個用途以外不相干的核心功能綁在一起暴露給 containers extension 使用：

• 新增、刪除獨立的 cookie 儲存空間，一個新的 contextualIdentities API 會自動建立一個新的 cookie 儲存空間，完全沒有考量到獨立的 cookie 儲存空間可能會有 contextualIdentities 以外的用途，也沒有考慮到新的 contextual identity 想要分享現存 cookies 的狀況（共用一個 cookie 儲存空間）。
• 更動右鍵選單項目，這個 API 直接自動新增了 “Open Link in New Container tab" 的項目。雖然我們已經有了 contextMenus API 可以新增右鍵選單項目，但顯然我們需要複製一份 code 給 contextualIdentities API 來讓使用者可以輕鬆地在新的 container 分頁裡面開啟連結，這樣複製一份 code 還可以減少 containers testpilot 插件開發者需要寫的 code ，非常棒。
• 在 tab 頁籤上色的功能，在每個 contextual identity 裡面可以新增 tab ，在 contextual identity 當中新增的 tab 會自動被上色。顯然在分頁上色的功能只會有 containers 實驗會用到。
• contextual identity 本身的頁籤顏色和圖示都只有固定的幾種可以選，圖示像是 cart, fingerprint, briefcase 等等，顯然不可能會有其他狀況下需要其他的圖示。

……正常的設計應該會是把前面三種功能分成三種不同的 API ， 插件作者自己把這三種 API 結合在一起形成 contextual identity 的概念才對啊！！

另外，雖然有了 contextualIdentities API ，但還缺乏很多 API ，導致這些插件的功能還沒辦法實作出完全復刻原本 quicksaver 開發的 Tab Groups 的功能：

• 如上所述，建立 contextual identity 的時候不能選擇共用 cookie store ，但 quicksaver 的版本裡面所有的分頁群組還是共用同一個 cookie store 的
  • 狀態：沒有查到相關的 feature request
• 沒辦法選擇性只顯示部分的分頁（也就是只能顯示所有的分頁），quicksaver 的 tab groups 一次只會顯示一個群組。
  • 狀態：開了一個 bug 在處理，Mozilla 已經批准這個 API 的設計： https://bugzilla.mozilla.org/show_bug.cgi?id=1384515
• 現在無法把某個 contextual identity 中的分頁移動到另一個 contextual identity ，只能關掉原本的分頁，然後開一個新的
  • Containers Testpilot 論壇上的討論： https://discourse.mozilla.org/t/move-tab-from-container-or-to-container/14134
• 如果要使用類似 tree-style tabs ，把所有分頁和分頁群組放到側邊欄，那原本的橫向頁籤列應該要被隱藏，但現在沒有這樣的 API
  • 狀態：開了一個 bug ： https://bugzilla.mozilla.org/show_bug.cgi?id=1332447

相關資料、討論

• https://discourse.mozilla.org/t/whats-all-this-about-sunsetting-tab-center/15999 討論 Testpilot 之前出過 Tab Center 實驗
• tabcenter-redux #36 Integration with Tab Groups https://github.com/eoger/tabcenter-redux/issues/36
• sea-containers 在論壇上面發佈： https://discourse.mozilla.org/t/sea-containers-sidebar-for-managing-tabs/15800
• denschub/firefox-tabgroups 作者承諾要在相關 API 出來之後把插件移植到 WebExtensions https://github.com/denschub/firefox-tabgroups/issues/60
• 論壇上面討論「能不能回復原本的 PANORAMA （分頁群組）功能」，裡面有人提到一些解法： https://discourse.mozilla.org/t/could-panorama-feature-be-brought-back-to-firefox/14672
• Quicksaver 說不會移植到 WebExtensions 之後有人開了 issue ，現在有許多分頁群組難民在那邊尋找希望： https://github.com/Quicksaver/Tab-Groups/issues/535

個人感想

原本我以為沒希望了，更久以前我在搜尋的時候都找不到替代方案，幸好最近有 containers testpilot 所以才有這麼多延伸應用冒出來，有種燃起一線希望的感覺。但上面的那些 bug 大部分都還沒有被 mozilla 批准，我不太有信心 57 出來的時候分頁群組替代方案能夠完全提供舊有的功能，感覺上面當中一兩個還是很有可能會被 mozilla 拒絕…

更新

TabHide API 出爐之後我調查了幾個目前的插件，尋找符合我需求的，紀錄文在此。