Mozilla Flux

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

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

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の方から以下のとおりコメントを頂いた。


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週間待った甲斐があったといえそうである。