Mozilla Flux

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

FirefoxのWindows XP/Vistaサポートが2017年9月で終了へ(追記あり)

Windows XP/Vista上のユーザーが通常版のサポートを受けるのは、Firefox 52で最後となり、その先は法人向け延長サポート版(ESR)に切り替わってサポートが続く(Bug 1318922)。つまり、Firefox 53ではなくFirefox ESR 52.1へと自動アップデートされる。

ESRに移行した後のXP/Vistaのサポート期間について、Mozillaは2016年12月23日(米国時間)、2017年9月までとする旨を発表した。これを受けて、重要: Firefox は Windows XP および Vista のサポートを終了します | Firefox ヘルプには、次のように記載されている。

私たちは、2017 年 9 月まで Windows XP および Vista のユーザー向けにセキュリティの更新を提供する予定です。しかし、これらのユーザー向けの更新には新機能が含まれません。私たちは、2017 年の中頃に、まだ Windows XP と Vista を使用しているユーザーに対して最後のサポート終了日をお知らせします。

Firefox ESR 52.3が2017年8月8日に、52.4が同年10月3日にそれぞれリリースされる予定となっており、上記発表の趣旨は、ESR 52.3を最後にWindows XP/Vistaのサポートを打ち切るということだろう。ただし、Mozillaは2017年半ばの時点でXP/Vista上のユーザー数を再評価し、サポート終了日を最終的にアナウンスするとしている。これは、XPにつき延長の余地を残すものだ。

筆者は、過去の記事で、ESRのサポート期間の途中でOSのサポートが打ち切られる可能性はまずないと述べたが、見事に予想を外してしまった。Mozillaがこれまでの慎重な姿勢を崩し、XP/Vistaのサポート期間を当初の計画よりも前倒しで終わらせることにしたのは、QuantumプロジェクトやWebExtensionsへの急激なシフトと無関係ではないだろう。Mozillaは選択と集中の傾向を強めており、たとえ一部のユーザーを切り捨てることになっても、Firefox/Geckoの刷新に注力して、新しいユーザーを獲得するほうに賭けるという態度が顕著になりつつある。要するにXP/Vistaのサポートは、選択されなかったのである。

この勢いだと、Firefox 52のリリースから1年後のFirefox 59では、Windows向け32bit版のサポートが終了するかもしれない。

(16/12/28追記)
Mozilla Japanの方から以下のとおりコメントを頂いた。


(17/10/05追記)
Update on Firefox support for Windows XP and Vista | Future Releasesが2017年10月4日付けで公開された。それによれば、Firefox ESRにおけるWindows XP/Vistaのサポートは、ESR 52のサポート終了と一致することになった。2018年6月25日まではサポートが続く。

Project Tofinoが遺したもの

Project TofinoからBrowser Futures Groupへ

Mozillaが2016年4月に開始したProject Tofinoは、Webブラウザのユーザーインターフェイス(UI)のコンセプトが仮に2016年に作られたらどうなるかを実験するプロジェクトである。当初は3か月の期間限定とされていたが、実際には延長されて8月頃まで続いていたようだ。プロジェクトの総括が公表されたのは、11月半ばになってからである。トップを務めるMark Mayo氏は、(Re)defining the Tofino Project – Project Tofino – Mediumの中で、プロジェクトがBrowser Futures Groupの研究へと発展的に解消していく旨を述べる一方、具体的な成果を示さなかった。

では、Project Tofinoは失敗だったのだろうか。評価を下す前に、このプロジェクトがどのように進展していったのかを見ておきたい。もともと、FirefoxのUXチームには、UIの刷新を目指すFawkesというプロジェクトがあった。Tofino自体、その発展型にあたる。FawkesのWindows 10向けモックアップを眺めれば、Microsoft Edgeの影響を受けていることは明らかだ。現在のFirefoxが採用するAustralisはChromeの影響を受けたデザインなので、どうやらMozillaは開発時点で最先端のデザインを応用するのが好みらしい。Tofinoの初期段階で、プロジェクトチームがこのFawkesのモックアップに近いデザインを実験したことが確認できる

ところが、本来ならプロジェクトも終盤に差しかかっているはずの6月上旬になって、これまでのデザインを白紙に戻すという決定が実行に移された(Tofino Project Goals Update – Project Tofino – Medium)。そして、プロジェクトチームは7月上旬に至っても、コンセプトを紙に起こし、簡単なモックアップを作る作業を繰り返していた(Iterations – Project Tofino – Medium)。この一連の動きは当時情報を追っていて謎だったのだが、今思えばこの時点で既に、プロジェクトの最後にデザイン案を大々的に打ち出すことは諦めていたのだろう。

おそらく、プロジェクトチームは、UIの抜本的な改良のためには何(what)を作るかと同時に、どう(how)作るかを同時に考えねばならず、一定の結論を得るにはかなりの試行錯誤が必要だと判断するに至ったのだ。ブラウザはユーザーにとってどのような存在であるべきなのか、そのためにはどんなデザインや機能が必要で、標準化された技術を用いてそれらを実現させるためには、どうしたらいいのか。また、UIに関してユーザーの「慣れ」の問題は避けて通れない。新たなデザインをどうやって受容してもらうかも重要だ。Tofinoはそうした検討課題について、解決の方向性を見極めるものとして終わったのではないか。そして、実際の結論はBrowser Futures Groupの研究に委ねることにしたのだろう。

将来のFirefoxに適用されるアーキテクチャ

Tofinoが見出した方向性の1つは、ブラウザをコンポーネントの集合と捉えずに、疎結合されたレイヤーの集積と捉えるというものだ。Engineering update on Tofino – Project Tofino – Mediumで説明されているところによれば、レンダリングエンジンは自己完結的になり、アプリケーションの他の部分とは、限定されかつ明確に定義されたポイントにおいて統合される。

そして、ユーザーの履歴やブックマークといったプロファイル情報は、ユーザーエージェントサービス(UAS)と呼ばれる独立したプロセスが管理し、ブラウザのメインプロセスやウィンドウなどは、すべてこのUASに接続することになる。接続方法は、HTTPとWeb Socketsだ。また、UASはクラウドと繋がって、ユーザーにとってのおすすめ情報を取得する。ここでは、ブラウザがユーザーの代理人として、適切に判断して行動するというコンセプトがある。

f:id:Rockridge:20161218180232p:plain

UASが管理するプロファイル情報は、Datomishと呼ばれるデータベースに格納される。DatomishはDataScriptの派生物で、Datomicデータベースシステムのアイデアを、ClojureScriptではなくRust言語で実現したものだ。持続的なストレージを前提にSQLite上に構築され、スケーラビリティに優れ、Firefoxへのデプロイも容易だという(Introducing Datomish, a flexible embedded knowledge store – Project Tofino – Medium)。

Mark Mayo氏の総括が重要なのは、こうしたコンセプトや要素技術が、将来のFirefoxに適用されると明らかにした点だ。Browser Futures Groupが行う研究は、年単位ではなく月単位だとしており、その後は当然実装の段階に移ると考えられる。別の言い方をすれば、MozillaはQuantumプロジェクトでGeckoを大改造するように、Firefoxのフロントエンドも大幅に刷新するつもりなのだ。

FirefoxというMozillaの基幹製品に手を付けるのだから、UIの作り方やパフォーマンスにこだわるのも当然だろう。Tofinoの総括の中で、ElectronとReactを利用したブラウザ構築の限界について相当の紙幅が割かれているのだが、その理由は、仮にMozillaがReactのようなフレームワークを作り、Positronと組み合わせたときに、Firefoxで使いものになりそうか探っていたためだと思われる。結果は、試作品の作成にはよいが、パフォーマンス面で製品化には必ずしも向いていないというものだったようで、Browser Futures Groupの研究においても、その解決策を見つけることが焦点の1つとなっている。

デザイン面での進展

Project Tofinoの総括の中で言及されていないため、あまり知られていないが、新UIのデザインも一応形はできていて、公開もされている。あえて言及しなかったからには、実際にFirefoxに取り込む時点でいろいろ変更があるのだろう。ただ、Tofinoのような集中的な検討の機会は滅多にない。現行のデザイン案がベースになる可能性は高い。

メインUIでは、タブバーにおけるOverview(概要)タブの存在が目を引く。タブブラウザのコンセプトは保たれているが、検索ボックスはなく、ナビゲーション関連のボタンはナビゲーションバーから分離されて左端にまとめられている。逆に右端には、Related Items(関連項目)が表示されている。なお、アクティブでないタブをホバーすると、要約が出るという。

f:id:Rockridge:20161218202934p:plain

ナビゲーションバー内には、保存ボタンのみが置かれる。保存ボタンを押すと選択画面が現れ、テキストとページ全体のスクリーンショットを保存できる。動画を保存することも可能だ。また、保存内容をまとめて「コレクション」にしておき、そこに追加するという使い方も想定されている。

f:id:Rockridge:20161218205302p:plain

保存ボタンをホバーすると、共有ボタンが出現する。共有ボタンを押すと選択画面が現れ、WebページをSNSやアプリで共有できるほか、自分宛にメールで送ることも可能だ。

f:id:Rockridge:20161218203649p:plain

ナビゲーションバーは、検索の起点でもある。現行のスマートロケーションバーと同様に、よく見るページなどが表示されるが、サムネイルをふんだんに使ってわかりやすくなっている。

f:id:Rockridge:20161218204131p:plain

関連項目は、閲覧中のページと関連する理由ごとに表示が区分けされる。どういった理由で、どんなコンテンツを表示するかは、Context Graphという別プロジェクトで研究中だ。

f:id:Rockridge:20161218204555p:plain

概要タブでは、現在開いているタブがサムネイルで一覧表示され、コレクションもリストアップされる。タブ一覧は履歴に切り替えることもできる。面白いのは、Archived Tabs(アーカイブされたタブ)という欄があることで、タブは閉じるのではなくアーカイブするもの、という発想に基づいているらしい。また、概要タブ内の情報は、ユーザーが入力した文字列によってフィルタリングが可能となっている。

f:id:Rockridge:20161218210105p:plain

使用されるサムネイルは、大型のものほど情報量が増え、たとえばAmazonで取り扱われている商品の場合、レーティングまで表示される。

f:id:Rockridge:20161218210306p:plain

次世代UIの基盤となったプロジェクト

最初の問いに戻ろう。Project Tofinoは、明確な成果を出せなかったという点では成功とは言えないが、未来のFirefoxの姿を素描できたという点では、失敗とは言えない。

11月の総括時点で、Browser Futures Groupのロードマップは策定中とされていた。2016年12月5日から9日まで、ハワイでMozillaのAll Handsミーティングが開かれており、おそらくそこでロードマップについても議論されたはずだ。筆者の予想では、Mozillaは2017年中に要素技術を確立しつつデザインを固め、2018年前半に新UIを製品版に投入してくるだろう。

(16/12/23追記)
本記事執筆後、Firefoxのビジュアル面の刷新を目指すPhoton(光子)というプロジェクトの存在が明らかにされた(Bug 1325171)。

デスクトップ版Firefox 57で拡張機能はWebExtensionsベースに限定化

Mozillaは、Add-ons in 2017 | Mozilla Add-ons Blogにおいて、Firefox 57のリリース(2017年11月28日:米国時間)に伴い、デスクトップ版ではWebExtensionsベースの拡張機能だけを読み込む措置を執る旨を明らかにした。XUL/XPCOMベースやAdd-on SDKベースの拡張機能(レガシー拡張機能)は、一切利用できなくなる。この措置を確実なものとするため、Mozilla Add-ons(AMO)では、Firefox 53のリリース(2017年4月18日:米国時間)に伴い、新規の拡張機能を登録する場合にWebExtensionsベースでないと受け付けなくなる。

現時点でのスケジュールは、Add-ons/2017 - MozillaWikiに詳しい。それによれば、Firefox 53のリリース時点で具体的に実施される措置は、AMOにおいて新規のレガシー拡張機能にデジタル署名を付さないというもの。既存のレガシー拡張機能がバージョンアップした場合は、従前どおり署名が付されるし、Android版Firefox向けやThunderbird/SeaMonkey向けの拡張機能には影響がない。

これがFirefox 57のリリース時点になると、デスクトップ版では本体が読み込むアドオンは次のものに限定されることになる。なお、Android版FirefoxやThunderbird/SeaMonkeyがどうなるかは、現時点で明らかにされていない。

  • 署名されたWebExtensions
  • 署名されたブートストラップ型システムアドオン
  • 言語パック
  • 辞書
  • OpenSearchプラグイン
  • 軽量テーマ

上記のリストを注意深く見れば、完全テーマ(XULベースのもの)が入っていないことに気付くだろう。Mozillaは現在、完全テーマと軽量テーマを統合した新テーマ(Bug 1306671)を開発中であり、この新テーマを実現するAPIはWebExtensionsの一部となる。つまり、新テーマは上記のリストのうち「署名されたWebExtensions」に該当するわけだ。

今からちょうど1年後には、レガシー拡張機能と完全テーマがことごとく機能を停止することになる。そのため、MozillaはこのときまでにChromeが提供する拡張機能向けAPIの大半をFirefoxでサポートしていく。アドオン作者は、既存の拡張機能/テーマをWebExtensionsベースに移植してAMOに登録すれば、自動アップデートによってレガシー版を置き換えることができる。既にEvernote Web Clipperのように実行した例もある。また、Firefox 51で導入される埋め込み型WebExtensionsの仕組みを利用して、レガシー拡張機能に含まれるWebExtensions部分を増やしていき、段階的に移行することも可能だ。

いうまでもなく、今回発表された措置がユーザーに与える影響は甚大である。レガシー拡張機能を使い続けるためFirefox ESR 52に乗り換える手もあるが、こちらも2018年6月中にはサポートが切れる。早めにインストールする拡張機能を整理し、WebExtensionsベースの代替物がないか探すといったことも必要になってきそうだ。

Firefox 50で拡張機能を入れた場合のパフォーマンスが改善

Firefox 50は、当初2016年11月8日(米国時間)に予定されていたリリースが、11月15日に延期されている。リリース直前に大きめの修正(Bug 1309350Bug 1309351)を入れたので、様子を見る必要があったというのが、延期の理由だ。

この修正により、Add-on SDKベースの拡張機能やモジュールローダを使用する拡張機能について、パフォーマンスが改善される。つまり拡張機能を積んだ環境の多くで、起動時を中心にFirefoxの処理がスピードアップする。そのうえ拡張機能を入れていなくても若干起動が早くなったとか、多数の拡張機能を入れている場合にシャットダウンが大幅に早くなったといった話もある。

MozillaがFirefox 50のリリースを遅らせてまで拡張機能を入れたときのパフォーマンスを引き上げようとしたのはなぜか。それは、Mozillaが最近Test Pilotという新機能の公開テストに力を入れていることと関係する。Test Pilotで公開されている拡張機能は、WebExtensionsではなくAdd-on SDKをベースに作られており、本体の改良がテスト機能の利用状況改善に直結するとの判断があるのだ。

実際に、Activity Streamのような処理の重いTest Pilot向け拡張機能を使っていると、本体の起動や最初の画面表示に要する時間は、Firefox 50で明らかに短縮されているのがわかる。拡張機能側のチューニングでは越えられなかった壁を、やすやすと越えていった感じだ。

使っている拡張機能の種類や数によって効果の現れ方は違うものの、ユーザーにとっては1週間待った甲斐があったといえそうである。

MozillaはQuantumプロジェクトで過去と訣別し、未来に賭ける

次世代のWebエンジンを構築

Mozillaが最近発表したQuantumプロジェクトは、Firefoxのエンジン部分にあたるGeckoを次世代のWebエンジンへと進化させ、パフォーマンスの飛躍的進歩(quantum leap:直訳は量子跳躍)をもたらす*1。Mozilla Corp.でHead of Platform Engineeringを務めるDavid Bryant氏が"A Quantum Leap for the Web"(和訳)と題する記事でそう発表し、かなりの反響を呼んだ。日本でもIT関係のメディアで多数取り上げられており、目にされた方も多いだろう。

Quantumプロジェクトの進展に伴い、GeckoにはServoの成果が取り込まれていく。ServoはMozillaが2012年ころから開発してきたブラウザエンジンの試作品であり、Rust言語によって構築されている。必然的に、GeckoもRust言語ベースのコンポーネントが増えていく*2。これによりメモリ安全性(Memory Safety)、すなわちプログラムによるメモリ破壊が不可能な状態を段階的に作り上げる。従来は、Geckoにrust(錆)が増えていくことからOxidization(酸化)と呼ばれていた*3が、今後はたとえばQuantization(量子化)と呼ばれるのかもしれない。

Geckoが進化した先にある次世代のWebエンジン(Next Generation Web Engine:以下NGWE)では、マルチコアが当たり前になったCPUに並列的な処理を行わせるとともに、高速化が著しいGPUへの処理のオフロード化も積極的に進める。David Bryant氏は、2017年末までに改善の大きな成果を提供すると明言しているほか、初期の成果は同年前半のうちに出せるだろうとも述べており、Servoの取り込みは急ピッチで進められそうだ。

ServoのパフォーマンスをFirefoxと比較した動画を見れば、その処理の滑らかさは一目瞭然である。通常のWebページでも長大なものになると差は歴然としており、表示時間が数分の1になるとの報告もある。NGWEの開発が進めば、その高速化をFirefoxユーザーも享受することができる。

www.youtube.com

NGWEはWindows、Mac、Linuxに加えてAndroid向けにも提供されるが、iOSに関してはAppleがWebKit以外のブラウザエンジンを認めない限り、Mozillaが提供しようと思ってもできない。また、後述するQuantum CSSの開発計画からすると、Android版NGWEの提供はデスクトップ版よりも遅れそうだ。

サブプロジェクトの成果を順次導入

Quantumプロジェクトは、いくつものサブプロジェクトから構成されている。それらのうち、本記事執筆時点でQuantum - MozillaWikiに掲載されているものを紹介しておこう。ただし、Mozilla's Project Quantum and Servoで言及されているとおり、これらのサブプロジェクトは始まりにすぎない。Servoで試作が完成した機能は、これからも順次NGWEに移植されていくことになるからだ。

Quantum CSS

Quantum CSSはStyloとも呼ばれ、ServoのCSSスタイルシステムをGeckoに統合する(Bug 1243581)。work stealingアルゴリズムを採用してレイアウトの並列処理を行い、増分レイアウトという手法で演算を最小化する。スタイルシステムとは、HTML要素にどのCSSスタイルを適用するかを決めるもの。Servoには高速かつ並列処理が可能なスタイルシステムが実装されており、これを踏まえてStyloでは、Style Resolutionとセレクタマッチングの並列化を行う。増分リスタイルと呼ばれる手法の導入も予定されている(Bug 1288278)。

Quantum CSSの導入は、担当部分の処理に関し、Firefoxユーザーの95%に対し少なくとも2倍の速度向上をもたらす。さらにその約半数のユーザーにおいては、4倍以上の速度になるという。開発の進捗状況を踏まえると、比較的早い段階でFirefoxに投入されそうだ。

Quantum Render

Quantum Renderは、Servoの次世代レンダラであるWebRenderをFirefoxのグラフィックスバックエンドに据える(Bug 1311790)。WebRenderはCSSの処理に特化し、GPU向けに最適化されているため、Chromeが採用しているSkiaよりも効率的だとされる。

Quantum Renderは、OpenGL ES 2.1またはOpenGL 3をサポートした環境で動作し、低レベルな(決め細やかな操作ができる一方で書かなければならないコード量が増える)APIを提供する。また、Retainedモードを採用し、マルチスレッド化されている。これまでGeckoが採用してきたMoz2D APIとの関係は明らかではないが、仮にグラフィックスAPIを全面的に新しくするのであれば、開発には相当な期間を要することだろう。

Quantum Compositor

Quantum CompositorはGeckoのcompositorに独立したプロセスを割り当てるもの(Bug 1264543)で、Servoとは別に「GPUプロセス」の名で開発が進められてきた。compositorは、Webページ内のいろいろな要素が複数のレイヤーにレンダリングされているのを1つにまとめ、スクリーンに送り出す。Firefoxのマルチプロセス化(e10s)に伴い、compositorは既にchromeプロセス内の独立したスレッドとなっているが、このcompositorスレッドがプロセスとして独立するわけだ。

Quantum CompositorはWindows版Nightlyで有効化が目前に迫っており(Bug 1314133)、機能の完成度の点からみれば2017年前半のうちにリリース版で有効化されてもおかしくない。ただ、Windows 7 SP1以降でDXGI 1.2をサポートするアップデートを導入した環境が必須とされている点(Bug 1297822)は気にかかる。Windows 7でも古い環境だとQuantum Compositorが有効にならないと知ったユーザーが、FirefoxのためにOSをアップデートしてくれるかといえば、答えは否だろう。リリース版で有効化されるタイミング(Bug 1307578参照)は、有効化できるユーザーの割合を考慮しつつ決めることになるのではないか。

Quantum DOM

Quantum DOMは、それぞれのタブ(あるいはiframe)を、分離され協調的にスケジューリングされたスレッドに割り当てることで、Webコンテンツの動作をよりスムーズなものとし、プチフリーズの発生を抑える。Mozilla’s Quantum Project | Bill McCloskey's Blogで説明されているように、ユーザースレッド(ユーザー空間で実装されたスレッド機構)を自前のスケジューラで管理し、優先順位を付けて切り替えていく。

多数のタブを開いていても、タブごとにプロセスを割り当てていけばプチフリーズの発生は抑制可能だ。Chromeは現にそうしている。だが、プロセス数の増加は消費メモリの増大につながる。Mozillaの調査研究の結果によれば、現状でcontentプロセスを8以上に増やすことは、メモリ使用量との関係で許容できない。そこで、プロセス内をマルチスレッド化してプチフリーズに対処することにした。マルチプロセスに加えて各プロセス内をマルチスレッド化することは、技術的に決して容易ではないものの、Mozillaはあえてそこにチャレンジする。

Quantum Flow

Quantum Flowは、他のQuantumコンポーネントによってカバーされない領域におけるパフォーマンスの改善を探究するもので、UI最適化が例として挙げられている。

開発プロセスの進化と脱XUL化の加速

Quantumプロジェクトの語られざる意義について、筆者の考えを述べておきたい。手短に言えば、このプロジェクトはWebブラウザの開発のあり方に一石を投じる一方で、従来のGeckoとの互換性をかなり犠牲にすることになるだろう。

まずは前者について。これまで、Firefoxの開発プロセスは、Nightlyから始まり、Auroraで機能をほぼ固め、Betaでテストを繰り返し、リリースに至るという連結列車モデルを採用してきた。大規模な修正を伴う新機能を開発する場合は、Nightlyチャンネルのリポジトリ(mozilla-central)を分岐させたブランチを作成し、適当なタイミングでmozilla-centralに再統合していた。Quantumプロジェクトでは、これらのプロセスの外側に、Servoという実験的なブラウザエンジンを置く形となる。

Webがリッチで複雑なものとなった現在、そのプラットフォームとなるブラウザも複雑化が不可避だ。ブラウザエンジンについても同様であり、革新的な機能を投入することは次第に難しくなっていくだろう。そうした状況のもとでは、過去のしがらみを考慮せずに自由に実験ができる、相対的に小型のブラウザエンジンというカードを持っておくことが強みとなる。なぜなら、巨大化して技術的負債を多く抱えたエンジンをベースに新機能を開発するよりも、実験的なエンジンで得られた成果を移植するほうがコストが少なくて済むからだ。Mozillaの狙いはおそらくこの点にある。

Servoの側から見ると、今後も独立した製品にならないことが決定したと言えそうだ。2014年を振り返ると、Servoをモバイル向け製品に使う話が出ていたし、Firefox OSの基盤に用いることを検討した形跡すらある。だが、Firefox OS自体、スマートフォン向けの開発が打ち切られたうえ、Connected Devices(IoT)にレンダリングエンジンは必須ではないとの判断が下されたことで、進路を絶たれた。Servoの行く末も、Geckoのテストベッドに求めるほかなくなった。

次に、後者について。Mozillaは「跳躍」の先にあるものを懸命に見せようとしているものの、大きく跳べば元の場所から遠く離れるわけで、当然その場所を前提にしていた技術は失われる。具体的には、XULだ。Servoの実験的なフロントエンドがBrowser.htmlと呼ばれていることからも明らかなように、ServoはXULを使用しない。前述したようにNGWEはServoの取り込みを急速に進めるから、脱XUL化もかつてないスピードで進展していくだろう。

これまでも従来型の拡張機能がFirefox本体のバージョンアップに伴って動かなくなることはあったが、本体の修正に追随すれば再び動作するようになる例が大半だった。しかし、脱XUL化は次元の違う問題だ。WebExtensionsベースに移行しない限り、拡張機能は存続できない。完全テーマも同様で、WebExtensionsの一部となる新しいテーマAPIを利用することが要求される。

Quantumプロジェクトが互換性をどれだけ犠牲にするかは、Mozilla自身が一番よくわかっているはず。それでもなお過去と訣別し、未来に賭けるほかないとの決意が、このプロジェクト名には込められている。そこまでしないと生き残れないというところまで、Mozillaは追い詰められているのだ。

(16/11/05追記)
さっそく詳しい人から指摘があったので、本文を修正した。

*1:Firefoxをマルチプロセス化したElectrolysis(電気分解)プロジェクトが分子に関係していたことを踏まえた名称とみられるが、エンジン部分の名称をQuantumに変えるわけではない。

*2:rust-bindgenというバインディングジェネレータを使用する。

*3:Firefox 48に新メディアパーザが最初のRust言語製コンポーネントとして搭載された話は、記憶に新しい。