Mozilla Flux

Mozilla関係の情報に特化したブログです。

Firefoxでレガシーなアドオンが使えるのは2017年11月半ばまで

窓の杜で既報だが、The Road to Firefox 57 – Compatibility Milestones | Mozilla Add-ons BlogでWebExtensionsへの移行プランが発表された。周辺情報も交えつつ解説しよう。

まず、今回の移行プランでは、WebExtensions限定化の時期がFirefox 57のリリース時(2017年11月14日:米国時間)であることが改めて確認された。昨年11月の発表以来、影響の甚大さゆえに先送りされるのではとの噂が絶えなかったが、Mozillaはそうした観測を否定した。

また、レガシーなアドオンの定義や、移行対象のプラットフォームが明確化された点も見逃せない。XUL/XPCOMベースやAdd-on SDKベースの拡張機能だけでなく、埋め込み型WebExtensionsと完全テーマもレガシーなアドオンに含まれる。ここに埋め込み型WebExtensionsが含まれるということは、Firefox 57以降、WebExtensions APIのみで構築された拡張機能しか動作が許されないことを意味する。そして、プラットフォームの面では、Thunderbird/SeaMonkey向けのアドオンが対象外であると明言された。逆に言えば、Android版FirefoxはWebExtensions限定化の影響を受けるわけだ。

マルチプロセス化(e10s)との関係

最近のFirefoxは、バージョンアップごとにマルチプロセス機能(e10s)が有効化される範囲を拡大してきている。拡張機能の互換性はe10sの有効・無効を決めるうえで大きな要素だ。Firefox 50の時点では、WebExtensionsベースの拡張機能のほか、作者がe10sと互換性あり(MPC=true)に設定した拡張機能がインストールされている場合にだけ、e10sが有効化されるようになっていたが、Firefox 51になって、ホワイトリストに掲載された700を優に超える拡張機能(Firefox Beta版でのテストを経て問題なしと判断されたもの)も、e10s有効化の妨げにならなくなった(Bug 1329015)。Firefox 52もほぼ同じ基準になるようだ。

移行プランにおけるFirefox 53のリリース時(2017年4月18日:米国時間)の記載は、こうした経過を踏まえたものである。Firefox 53では、作者がe10sと互換性なし(MPC=false)に設定しない限り、e10sは有効化されるのが原則。例外的に、Mozillaが互換性に問題ありと判断した拡張機能がインストールされているとe10sを無効化する。

e10sの原則有効化と歩調を合わせるようにして、Mozilla Add-ons(AMO)ではレガシーアドオンの新規投稿を受け付けなくなる。既存のレガシーアドオンの更新は可能だが、野良アドオンにデジタル署名を付すことができなくなるとみられ、少なからず影響が出そうだ。

WebExtensionsの別プロセス化

移行プランでは、Firefox 54から56までに関する言及は少ない。Firefox本体のcontentプロセスの複数化(e10s-multi)とサンドボックス化の進展によって、レガシーなアドオンに互換性の問題が生じるかもしれないと記載されているのみだ。

だが、この間にWebExtensionsベースの拡張機能はFirefox本体のプロセスから独立して動作するようになる可能性が高い(Bug 1190679)。この拡張機能専用プロセスは、本体よりも強固なサンドボックス化が施される予定である(Bug 1334557)。ただ、Chromeのように拡張機能ごとにプロセスを割り当てることまではしない。

WebExtensions限定化

Firefox 57のリリース時にWebExtensions限定化の措置が執られた後も、AMOではレガシーなアドオンの掲載を続け、作者が更新できるようにする。掲載をいつまで続けるかは現在のところ未定だ。

WebExtensions限定化の措置はNightlyチャンネルから順に投入されていくため、Firefox Nightly 57のユーザーは、より早い段階で措置の影響を受ける。もっとも、Nightly/Auroraチャンネルに関しては、レガシーなアドオンをインストール可能にする設定が導入される可能性が高い。Nightly/Auroraチャンネルにはアドオンのデジタル署名チェックを回避する設定もあるため、AMOからレガシーなアドオンが排除された後も、Firefox本体の設定が残っている限り修正版を野良アドオンとして利用することができそうだ。ただ、Firefox本体に搭載されたe10sとの互換性を保つための仕組み(e10s shim)が削除されるため、本当に古い拡張機能はどうしようもない。

最後に、Mozilla Corp.でAdd-ons Developer Relations Leadを務めるJorge Villalobos氏による今回の移行プランに関するコメントを紹介しておく。

I fully admit the timing was bad. The opportunity and resources to launch WebExtensions came up when we were already into the initial e10s migration process, and the plans for Firefox also shifted in a way that WebExtensions can be the only path forward. We can’t support legacy add-ons for 2 years more because the APIs they rely on won’t exist then. Supporting them for longer only means extending the frustration of constant breakage, both for developers and users.

タイミングが悪かったことは完全に認める。WebExtensionsを起ち上げる機会とリソースが出てきたときには、既にe10sへの移行プロセスが始まっていたし、Firefoxの計画も変わって、WebExtensions以外に進める道はない。依存しているAPIがなくなってしまうので、レガシーなアドオンをもう2年サポートしろと言われても無理なんだ。サポート期間を延ばしても、頻繁に動かなくなってフラストレーションが溜まるだけだよ。開発者にとっても、ユーザーにとってもね。

現在開いているタブの隣に新規タブを開く(Firefox 51以降)

既にはてなブックマークには記録した情報で、Twitterにも流しているが、使っていて便利な機能なのでブログでも紹介しておきたい。

Firefoxのタブバーには、一番右端に表示されているタブの右隣に新規タブボタンがある。「+」のアイコンが目印だ。このアイコンをクリックすると、全タブの最右端に新規タブが開かれる。この「全タブの最右端」というのがくせもので、既に多数のタブがある場合、タブバーがスクロールして新規タブが表示されることになるため、直前まで開いていたタブがタブバーから消えてしまう。

Firefox 51では、Ctrlキーを押しながら新規タブボタンをクリックすることで、現在開いているタブ(以下「アクティブなタブ」)の隣に新規タブが開かれるようになった(Bug 528005)。直前まで開いていたタブの脇に新規タブをドラッグする手間が省けるわけだ。

f:id:Rockridge:20170212174237p:plain

ちなみに、常にアクティブなタブの右隣に新規タブを表示させるための拡張機能も存在する。Always Rightがそれで、Mozillaの中の人が作者なのでFirefoxの仕様変更がある際にも対応してくれそうだ。

ただ、「常に」ということなので、あるページのリンクを順次新しいタブで開いていく場合、後で開いたものほどアクティブなタブの右隣に来る。好みが分かれるところだろう。

(17/02/12追記)

Firefox 51から53までWebゲームプラットフォームとしての機能を段階的に強化(再追記あり)

MozillaはこれまでもFirefoxをWebゲームの強力なプラットフォームにすべく改良を重ねてきたが、Firefox 51以降の3バージョンの間にそのステージを1段階引き上げる。3Dの表現力だけならPlayStation 3/Xbox 360世代に匹敵する水準となり、ゲームのロードから開始までの時間が短縮され、動作の安定性も向上する。具体的にどのような変化が起きるのか紹介しよう。

Firefox 51

最近リリースされたFirefox 51では、WebGL 2が初期設定で有効化された。これを踏まえたプレイアブルなデモが、PlayCanvasの"After the Flood"である。大洪水後の荒廃した未来の町並みが美しいグラフィックスで描写されており、2012年3月に公開されたBrowserQuestと比べると、表現力の進歩を実感できるだろう。

www.youtube.com

WebGL 2はOpenGL ES 3.0がベースになっており、WebGL 1(OpenGL ES 2.0ベース)とは緩やかな後方互換性を保っている。WebGL 2の処理パイプラインの構造はWebGL 1のものをほとんど踏襲しているが、新機能の追加によって3D APIの表現力が増強されている。たとえば複数のテクスチャに対し同時に書き込みができるようになり(Multiple render targets)、複数のインスタンスを1回の描画命令で描画することが可能になった(Instanced geometry drawing)。また、3Dテクスチャや2Dテクスチャ配列がサポートされ、頂点シェーダで計算した結果を頂点バッファオブジェクトに書き込むこともできる(Transform feedback)。

Mozillaは今後、WebGL 2 APIのパフォーマンスを向上させるほか、一部の制約を緩和するなどAPI自体も洗練させていくとしている。

Firefox 52

Firefox 52ではWebAssemblyが初期設定で有効化される予定だ。JavaScriptのサブセットにすぎないasm.jsとは異なり、WebAssemblyはバイナリフォーマットを採用しているのでコンパクトだ。2016年3月時点で、そのサイズは非圧縮のasm.jsよりも42%小さいとされていた。現在はさらに差が開いている可能性がある。

パフォーマンスの面でも、WebAssemblyはasm.jsよりも良好なスループットを達成している。また、コンパイル時間の短縮も図られており、Unityのテストで3420ミリ秒から1492ミリ秒になったという話もある(Bug 1317033)。

このWebAssemblyに関連して、Large-Allocation Headerという機能が32bit版向けにFirefox 52で有効化されるかもしれない(Bug 1331083)。この機能はマルチプロセス化(e10s)を前提にするもので、ドキュメントにこのヘッダが付いていると、読み込み予定のページに独立したプロセスが割り当てられる。そのプロセスでは大量の連続的なメモリを確保できるので、WebAssemblyベースのゲームを読み込む際に有効であるというわけだ。

以上とは別に、Firefox 52ではSharedArrayBufferおよびAtomics APIが初期設定で有効化される(Bug 1312446)。SharedArrayBufferは、スレッド間で共同利用できるバッファを作ることができるというもので、そのバッファの操作やスレッドの制御を行うのがAtomics APIだ。

SharedArrayBufferが導入された背景については、A Taste of JavaScript’s New Parallel Primitives ★ Mozilla Hacksに説明がある。その和訳であるJavaScript の並列処理機能を味見してみる | Mozilla Developer Street (modest)から引用しておく。

これらに代表される JS (注:JavaScript)の適用範囲の拡大は、パフォーマンスの驚異的な改善によって可能となりました。それは JS エンジンに実装された Just-in-Time(JIT) コンパイラや、より高速な CPU によってもたらされました。

しかし、JIT による実行速度向上のスピードは低下しつつあります。また CPU 速度の改善はほとんど頭打ちになっています。CPU の高速化に代わる手法として利用されているのは、複数の CPU(実際は CPU のコア)の利用です。これは携帯電話からデスクトップにいたるまで広く利用され、ローエンドの環境を除けば、最低でも 2 つ以上の CPU が利用できるようになっています。このような状況でプログラマがプログラムの性能を向上させたいなら、複数のコアの並列利用を選択するでしょう。これは Java、Swift、C#、C++ のようなマルチスレッドプログラミングが可能な言語で書かれたネイティブアプリの話ではありません。Web Worker と、その遅いメッセージパッシング機構、そしてデータコピーの回避手段がほとんどないという、複数の CPU を利用するには極めて制限された機能しか持たない JavaScript での話です。

つまりは JS には問題があるのです:Web 上の JS アプリケーションが、ネイティブに代わる有力な選択肢であり続けるためには、JS を複数 CPU の上で動作させられるような機能を JS に持たせなければなりません。

要するにSharedArrayBufferは、PC側の複数CPUコアを利用して、並列に計算させることでJavaScriptの処理速度を向上させるための仕組みだ。重いゲームを動かす際に力を発揮することは、いうまでもない。

Firefox 53

Firefox 53では、別記事に書いたとおり、適格性のあるWindowsユーザーに対し軽量インストーラ(スタブインストーラ)が初期設定で64bit版をインストールするようになる(Bug 797208)。64bit版はOOM(out of memory:低メモリ)クラッシュが減って安定性が向上するだけでなく、パフォーマンスも向上することがベンチマーク結果から明らかになっている。

Windows版でQuantum Compositor(旧名GPUプロセス)が初期設定で有効化される点も見逃せない(Bug 1330554)。Geckoのcompositorに独立したプロセスを割り当てるこの機能は、GPUドライバが原因のクラッシュを45%も減少させる。64bit版である場合やDirect3D 11を使用する場合には、クラッシュ率を全般的に引き下げる効果も認められている。

(17/02/12追記)
Firefox 51以降の動きを紹介する主旨なので本文では触れていないが、2016年中にWeb Audio APIの仕様変更に追随するなど、オーディオ面でも性能は向上している。

(17/03/09追記)
Firefox 52の初期設定でWebAssemblyが有効化された(Bug 1342060)。他方、Large-Allocationヘッダは、Firefox 53(32bit版のみ)で有効化される見通しである。

(17/03/13追記)
WebAssembly + WebGL 2.0を駆使したZen Gardenデモが公開されている。高精細な3D画面が次々に展開されていく美麗なデモではあるが、ファイルサイズが約100MBあり、動作にかなりのマシンパワーとメモリを必要とする。Webの最先端を示すものといえよう。

www.youtube.com

その一方で、軽量インストーラが初期設定で64bit版をインストールするようになる時期は、Firefox 55へと後退した。64bit版でFlashの非同期レンダリングのサポートが遅れていることが原因である。ただ、Firefox 53のWindows向けインストーラでは、オプション画面でユーザーが32bit版と64bit版のいずれをインストールするか選択できる

(17/05/03追記)
Firefox 52/53ではSharedArrayBufferおよびAtomics APIの有効化が見送られた(Bug 1342095Bug 1354160)。投入はFirefox 54となる。

(17/05/14追記)
SharedArrayBufferおよびAtomics APIの有効化はFirefox 55へと延期された

2017年10月上旬までにWindows向け64bit版Firefoxの自動アップデートが開始(追記あり)

Mozillaは、米国時間の2017年3月7日にリリース予定のFirefox 52でAdobe Flash以外のプラグインのサポートを終了させた後、64bit版へのシフトを本格的に進めていく。

同年4月18日にリリース予定のFirefox 53では、適格性のあるWindowsユーザーに対し軽量インストーラ(スタブインストーラ)が初期設定で64bit版をインストールするようになる(Bug 797208)。適格性のあるWindowsユーザーとは、64bit版Windows 7以降を使用し、3.8GB以上の仮想アドレス空間にアクセス可能なハードウェアを使用しているユーザーのことをいう。物理メモリは64bit版Windows 7以降の動作環境である2GBを満たしていればOK。なお、OS X(macOS)向けFirefox 53は、Intel 64bit版に一本化される(Bug 1295375)。

そして、Firefox/Win64 - MozillaWikiおよびその改版履歴によれば、適格性のあるWindowsユーザーが32bit版Firefoxを使用している場合、2017年8月8日にリリース予定のFirefox 55か、同年10月3日にリリース予定のFirefox 56で、64bit版への自動アップデートが行われる。

自動アップデートの時期がFirefox 55と56のいずれになるかは、予想の難しいところだが、最近のMozillaのアグレッシブな姿勢からすると、Firefox 55のほうが可能性が高そうだ。もっとも、Firefox 55の時点では対象ユーザーの30%程度にアップデートの提供をとどめておき、発見された問題を潰したうえで、Firefox 56において100%に引き上げるといったことも考えられる。いずれにせよ、おそらく2017年末には、64bit版Firefoxのユーザー数が32bit版のそれを上回っているだろう。

(17/01/21追記)
本記事執筆後、Firefox/Roadmap - MozillaWikiにおいて自動アップデートの時期がFirefox 55になると発表された。

(17/05/09追記)
本文で記載したプランは変更されている。Firefox/Win64 - MozillaWikiの最新情報によれば、軽量インストーラ(スタブインストーラ)が初期設定で64bit版をインストールするようになるのは、Firefox 55からである。また、64bit版への自動アップデートは、Firefox 56.0.1のリリースとともに行われる。ただ、Firefox 56のリリース時期が9月26日に前倒しされたため、10月上旬までに自動アップデート開始という点は実現されそうだ。

(17/09/18追記)
最新の情報をMozillaがWindows向けFirefox 56.0に対し64bit版56.0.1への自動アップデートを提供予定 - Mozilla Fluxに記載したので、そちらも併せて参照してほしい。

Chrome向けFeedlyはてブ拡張をFirefoxで使う方法

2016年末にFeedlyをはてブ対応させるChromeエクステンションがChromeウェブストアで公開された。Otchy氏が自作のユーザースクリプトを拡張機能化したもので、Feedlyのリスト画面にはてなブックマークの数を表示してくれる。

ユーザースクリプト版がFeedlyの仕様変更に伴って動かなくなっていたので、開発が再開されたのは嬉しい限り。しかし、Chrome向け拡張機能なので、これまでみたいにFirefoxにGreasemonkeyを入れて使うというわけにはいかない。何とか動かす方法はないものか。

Chrome Store Foxified(以下CSF拡張)を使うのがよさそうだ。この拡張機能をFirefoxにインストールした状態で、Feedly はてブ - Chrome ウェブストアを開く。すると、ふだん右上隅に「CHROME に追加」と出るところが、「ADD TO FIREFOX」へと変わっているはずだ。これをクリックする。

f:id:Rockridge:20170109182106p:plain

CSF拡張のメニューが出てくるので、自分が使用するFirefoxのチャンネルを踏まえて選択する。たとえばNightly/Auroraチャンネルであれば、「Save Unsigned Addon to File」を選択し、保存したXPI形式のファイルをアドオンマネージャからインストールすればOK。予めxpinstall.signatures.requiredの設定をfalseに変えておくのを忘れずに。Mozilla Add-ons(AMO)からデジタル署名を得ていない拡張機能を使えるようにしておく。

f:id:Rockridge:20170109183429p:plain

Beta/リリースチャンネルの場合、もう少し手間がかかる。AMOのデジタル署名が必須なためだが、CSF拡張には「Sign Add-on then Install」という選択肢がちゃんと用意されている。ただし、AMOへのログインが必要なので、Add-ons for Firefoxのページの最上段に「ユーザー登録 / ログイン」とある箇所から事前にログインしておく。ここで要求されるのはFirefoxアカウント。Firefox Syncを使っているなら、既に持っているはずだ。ちなみに、AMO独自のアカウントは2016年8月31日をもって廃止された

CSF拡張が素晴らしいのは、AMOから非公開のアドオンとしてデジタル署名を取得する処理を、自動で行ってくれる点。しかも、UUIDの衝突を回避する仕組みを備えており、ユーザーはAMOに近い感覚でChromeウェブストアの拡張機能をインストールできる。

Feedlyはてブ拡張がインストールできたら、Feedlyを開いてみよう。はてなブックマークの数が表示されているはずだ。筆者はFirefox 50.1.0で動作を確認した。なお、当然ながらアドオン作者の保証外の行為だし、自動アップデートもできない。

f:id:Rockridge:20170109190048p:plain

作者のOtchy氏は以下のように述べているが、ECMAScript Next support in Mozilla - JavaScript | MDNのとおり、FirefoxでもES2016のサポートは着実に進んでいる。Webの互換性が確保されている状況も、素敵な事ではないだろうか。

もともと書いていたユーザースクリプトが動かなくなって、エクステンションが必須だな、となった後もしばらく重い腰を上げられなかったのは、やはり上記で説明したような諸々が面倒そうだなー、と思っていたからでした。その重い腰を上げるきっかけになった一つは、そう、Chrome だけがターゲットという事は、「生の ES2016 で書いて問題無い」という事に気づいたからです。何と素敵な事でしょう。

超最低限の Chrome エクステンションを開発しウェブストアで公開するまでの手順 - Qiita