読者です 読者をやめる 読者になる 読者になる

Mozilla Flux

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

Firefox 52からWindows XPはESRでのサポートへ移行 Vistaもやや遅れて追随か

Fx新着

Firefoxが通常版でWindows XPをサポートするのはバージョン51までであることが明らかになった。バージョン52以降は法人向け延長サポート版(ESR)でのみサポートされる(Bug 1303827)。

もともとこの話はFirefox 46のリリース前からあって、XP上のFirefoxユーザーの数に配慮した結果、先送りになっていた。Mozilla Corp.の従業員からも、サポートを変更するタイミングとしてはFirefox ESR 52のリリース時という観測が出ていたので、意外感は全くない。

Firefox 52のリリース(2017年3月7日予定)と同時なのか、それとも多少遅れるのかは定かでないものの、XP上のFirefox 51ユーザーに対してはESR 52の自動アップデートが提供されることになりそうだ。2016年3月時点で既に、そうした措置は技術的に十分可能だとされており、そこに1年分のリリースエンジニアリングの進歩が加われば、ますます簡単だろう。

Firefoxは変則的なリリース間隔を採用しているが、これは要するにESRのベースとなるバージョンのリリース時期を毎年同じくらいの時期にするものなので、ESRのサポート終了時期の予測は立てやすい。ESR 45.8のサポートが2017年6月12日まで続くことからすると、ESR 52.8のサポートが終了するのは、2018年6月のどこかになるはずだ。Microsoftのサポートが2014年4月8日に終了していることを考えると、かなり手厚い措置といえるのではないか。

XPのサポートがESRに移行すると決まったことで、俄然注目されるのはWindows Vistaの扱いである。こちらは2017年4月11日にMicrosoftのサポートが切れる。Firefox 52のリリース後だが、Firefox 53のリリース(2017年4月18日予定)よりは前なので、Vista上のFirefox 52ユーザーにESR 52.1を提供すれば、ダウングレードにはならない。

サポートするOSを減らせば、Mozillaとしては製品版リリースまでに行われる各種テストを絞り込めるだけでなく、外部から取り入れているオープンソースのコードが、FirefoxのサポートしているOSに合わないといった問題も避けられる。たとえば、プロセスのサンドボックス化にChromiumのコードを使おうとすると、GoogleがXP/Vistaのサポートを打ち切っているので古いバージョンしか選べないという状況は、FirefoxのサポートOSをChrome(Chromium)と同じにしてしまえば解決するわけだ。

しかも、最近Mozillaは64bit版Firefoxの本格提供に向けて動き出したが、64bit版はWindows 7以降しかサポートしていないため、64bit版が主流になると32bit版だけVistaのサポートを追加する格好になる。また、Firefoxの基盤にあたるGeckoにServoという新開発のブラウザエンジンの技術を取り入れていく話についても、ServoがやはりWindows 7以降しかサポートしないので、Vistaのサポートを残し続けると移植の障害になりかねない。

そのうえ、VistaのマーケットシェアはXPよりもはるかに小さいので、ESRへの移行がFirefoxユーザー全体の中で与えるインパクトも限定的だ。Vista上のユーザーにとっても、Chromeがさっさと撤収する中、MicrosoftのOSサポートが切れてから1年以上もブラウザのサポートを受けられるのは、決して悪い話ではない。

こうして見てくると、MozillaがWindows XPに引き続きVistaも同様の扱いとする可能性は非常に高いといえるだろう。

関連記事

Windows向けFirefox 52で64bit版が主役に 2017年後半には自動アップデートも提供へ

Windows向け64bit版Firefoxは、2014年11月に発表されたプランからすると提供がかなり遅れており、Mozillaとしても慎重ならざるを得なかったのか、これまで新たな計画が明らかにされることはなかった。だが、ここにきてFirefox/Win64 - MozillaWikiに具体的なスケジュールが掲載されるようになり、本腰を入れてきた感がある。

上記のスケジュールは、1つひとつが簡潔な記載になっているため、読み解くには様々な情報と突き合わせる必要がある。現在判明しているところでは、まず、2016年9月下旬から10月上旬にかけて、新しいダウンロードページのテストが実施される。Firefox 50のリリース予定日が11月8日(米国時間。以下同じ)であることを踏まえたものとみられ、おそらくそのリリースに合わせて、MozillaのWebサイトのトップページから64bit版Firefoxのスタンドアローン型インストーラ(フルインストーラ)への導線が強化される。

次のステップはFirefox 52で、適格性のあるユーザーに対しては、軽量インストーラ(スタブインストーラ)が初期設定で64bit版をインストールするようになる(Bug 797208)。ここで、適格性のあるユーザーとは、搭載メモリが4GB以上のPCでWindows 7以降のOSを使用しているユーザーを指す*1。軽量インストーラはMozillaのWebサイト以外でも広く公開されており、多くのユーザーがこの時点で64bit版に触れる機会を持つことになるはずだ。脇役だった64bit版は、ついに32bit版を押しのけて主役となるわけだ。ちなみに、かつてのプランでは、軽量インストーラに64bit版が統合され、ユーザーが選択できるようになるのがフェーズ2とされていた。今回のスケジュールは、64bit版を初期設定にした点が目新しい。

最後に、2017年後半には、適格性のあるユーザーが32bit版を使用している場合、64bit版が自動アップデートで提供される(Bug 1274659)。かつてのプランでフェーズ3と呼ばれていた段階であり、ここまできてようやく、2014年11月に発表されたプランが完遂されたことになる。Firefoxのリリーススケジュールを見ると、2017年の後半にリリースされるのは3バージョン。すなわち、8月8日リリースのFirefox 55、10月3日リリースのFirefox 56、11月28日リリースのFirefox 57だ。MozillaWikiの改版履歴をチェックするとわかるが、当初は2017年第2・第3四半期となっていたものが、単に第3四半期とせず、後半に変更されている。つまり第4四半期にずれ込むことを考慮したわけで、Firefox 56が暫定的なターゲットではないか。*2

スケジュール通り進められるかどうかは、前提条件を確保できるか否かにかかっている。MozillaはFirefox 52でFlash以外のNPAPIプラグインのサポートを廃止することにしているが、この予定が延びてしまうと、64bit版を主役にするという計画にも狂いが生じる。また、FlashプラグインについてMozillaは自前でサンドボックス化を実現していくが、これに関連するバグを潰しきれるかという問題がある。さらにいえば、バイナリベースの拡張機能に関し、XPCOMによるものは既にFirefox 41で廃止されたが、js-ctypesによるものの廃止にあたっては、WebExtensionsによる代替機能の提供を考慮する必要があるかもしれない

64bit版への移行は、ポインタサイズが倍になる関係で消費メモリが25%増しになるというデメリットもあるが、処理の高速化に加えて、アドレス空間消尽の問題がなく、アドレス空間配置のランダム化(ASLR)が強化されてセキュリティが向上するなど、メリットも大きい。今回のスケジュールのまま開発が進むことを期待したい。

関連記事

*1:Windows向け64bit版FirefoxはWindows 7以降でしか動作しない。

*2:ちなみに、OS X向けFirefox 53では、Windows向けに先んじてビルドがIntel 64bit版に一本化される見込み(Bug 1295375)。

Firefoxは2017年も変則的なリリース間隔を採用

Fx新着

2016年に入ってから、Firefoxのメジャーアップデートのリリース間隔は6週間に固定されなくなったが、この方針は2017年も継続される。RapidRelease/Calendar - MozillaWikiに記載されているとおり、6週間から8週間の変則的なスケジュールが採用され、年に7回のメジャーアップデートが行われる。

以下がその内容だ(米国時間ベース)。なお、2017年のクリスマス付近にリリース予定日が重ならないため、50.0.1のような特殊なスケジュールは組まれていない。

リリース予定日 正式版 ESR
2016-11-08 Firefox 50 Firefox 45.5
2016-12-13 Firefox 50.0.1 Firefox 45.5.1
2017-01-24 Firefox 51 Firefox 45.6
2017-03-07 Firefox 52 Firefox 45.7; 52.0
2017-04-18 Firefox 53 Firefox 45.8; 52.1
2017-06-13 Firefox 54 Firefox 52.2
2017-08-08 Firefox 55 Firefox 52.3
2017-10-03 Firefox 56 Firefox 52.4
2017-11-28 Firefox 57 Firefox 52.5
2018-01-22 Firefox 58 Firefox 52.6

変則的なスケジュールの場合、過去のように年8回のメジャーアップデートを行うことができなくなる一方、Update on 2016 Firefox Release Schedule | Future Releasesで指摘されているように、OSの大型アップデートなどのイベントに合わせてリリースのタイミングを柔軟に調整できる。また、今回、Firefox 49のリリースはバグ潰しのために1週間遅れたわけだが、こうしたことがあってもFirefox 50のリリース予定日を維持できるのは、スケジュールに余裕をもたせてあるからだ。

ESR(延長サポート版)についても、正式版のリリースサイクルが延びることは延長サポート期間が延びることを意味する。安定した環境を求めるユーザーにとって、サイクルが6週間固定でないことの恩恵は大きいといえるだろう。

2年続けて同様のスケジュールを採用し、しかも早々とこの時期(正確には2016年8月末)に2017年の予定を打ち出しているところをみると、Mozillaは今後もこのリリース間隔を維持していくと思われる。

Placesデータベースの読み書き処理を大きく減らす裏技(Firefox 49以降)

Fx解説

Firefoxはブラウジング履歴やブックマークなどの情報をPlacesと呼ばれるSQLiteデータベースに記録している。Placesが壊れてしまうとブックマークが失われたり、ロケーションバーからうまく候補を呼び出せなくなったりするため、FirefoxはジャーナルモードというSQLiteの機能を利用して、データベースの保護に努めている。

Placesを保護する手段の1つが、ログ先行書き込み(WAL:Write-Ahead Logging)だ。SQLiteでは、トランザクション開始から終了までの更新内容を順次「-shm」ファイルに書き込み、コミット時に「-wal」ファイルへと更新内容を書き込む*1。コミットした時点では本体データベースファイルに更新内容を書き込まないため、クラッシュしても本体は無傷で残り、トランザクションも迅速に完了できるというわけだ。Placesの場合、このWALジャーナリングモードが初期設定で有効化されており、本体であるplaces.sqliteのほかに、places.sqlite-shmとplaces.sqlite-walという2つのログファイルが作成される。

これとは別に、PlacesではFULL同期モードが初期設定で採用されており、コンテンツが安全にデータベースに書き込まれたのを確認してから次の処理に進むようになっている。SQLiteの公式サイトの説明によれば、WALジャーナリングモードは通常NORMAL同期モードと呼ばれる相対的に軽い処理のモードを採用することが一般的らしい。あえて重いモードを選択しているあたり、Placesを厳重に保護しようとするMozillaの判断がうかがえる。

だが、これらの保護措置はFirefoxのテスト自動化にとって妨げとなる。大量のディスク入出力(I/O)が発生するからだ。そこで、Firefox 49ではWALジャーナリングモードとFULL同期モードを両方オフにする隠し設定が導入された(Bug 1272025)。これにより、Firefoxの自動テストのような負荷の高い環境では、ギガバイト単位でディスクI/Oを節約できるという。

危険度の高い変更であるため、隠し設定は通常よりも複雑なものとなっている。まず、about:configの画面でplaces.database.disableDurabilityの設定を新規作成し、真偽値をtrueにする。次に、環境変数を追加する。設定値は何でもよく、変数の存在だけが重要だ。ALLOW_PLACES_DATABASE_TO_LOSE_DATA_AND_BECOME_CORRUPTがそれだ。Windowsだとコントロールパネルの「システムの詳細設定」からユーザー環境変数を追加できる。トラブルシューティング情報(about:support)からプロファイルフォルダを開き、places.sqlite-shmとplaces.sqlite-walのファイルが消えていることを確認できれば成功だ。

隠し設定が有効化されると、WALジャーナリングモードはMEMORYジャーナリングモードへと変更され、ロールバックジャーナルと呼ばれるデータベースのバックアップがメモリ上に作成されるようになる。書き込みは直接Placesデータベースに対し行われるので、ログの読み書き分のディスクI/Oがなくなるわけだ。しかも、Placesへの書き込み完了を待たずに次の処理へ移るため、ユーザー側からは書き込み処理に要する時間も短縮されたように見える。

一般ユーザーが使用することを想定していない裏技ではあるが、履歴やブックマークの完全性よりもFirefoxの動作の高速性を選びたいマニア向けに紹介しておく。

Firefox 49でChrome・Safariを基準に作成されたコンテンツの表示精度が向上

Fx情報

Firefox 49では、既存のコンテンツとの互換性を高めるため、-webkit-のベンダープレフィックス(以下「webkit接頭辞」)がついたCSSプロパティや属性を多数サポートしている。layout.css.prefixes.webkitが初期設定で有効化される(Bug 1259345)ことによるもので、ベータ版リリースノートには掲載されていないが、Chrome・Safariを基準に作成されたコンテンツの表示精度が向上するため、一般ユーザーにとっても重要な変更といえるだろう。

サポート対象となる具体的なプロパティや属性については、MDNのFirefox 49 for developersにまとめられている*1。が、初期設定で無効のものが混じっているなど若干煩雑なので、改めて整理しつつ列挙しておこう。

-webkit接頭辞がついていても動作するプロパティ

  1. -webkit-align-items
  2. -webkit-align-content
  3. -webkit-align-self
  4. -webkit-animation
  5. -webkit-animation-delay
  6. -webkit-animation-direction
  7. -webkit-animation-duration
  8. -webkit-animation-fill-mode
  9. -webkit-animation-iteration-count
  10. -webkit-animation-name
  11. -webkit-animation-play-state
  12. -webkit-animation-timing-function
  13. -webkit-backface-visibility
  14. -webkit-background-clip
  15. -webkit-background-origin
  16. -webkit-background-size
  17. -webkit-border-bottom-left-radius
  18. -webkit-border-bottom-right-radius
  19. -webkit-border-image
  20. -webkit-border-top-left-radius
  21. -webkit-border-top-right-radius
  22. -webkit-border-radius
  23. -webkit-box-shadow
  24. -webkit-filter
  25. -webkit-flex
  26. -webkit-flex-basis
  27. -webkit-flex-direction
  28. -webkit-flex-flow
  29. -webkit-flex-grow
  30. -webkit-flex-shrink
  31. -webkit-flex-wrap
  32. -webkit-justify-content
  33. -webkit-order
  34. -webkit-perspective
  35. -webkit-perspective-origin
  36. -webkit-text-size-adjust
  37. -webkit-transform
  38. -webkit-transform-origin
  39. -webkit-transform-style
  40. -webkit-transition
  41. -webkit-transition-delay
  42. -webkit-transition-duration
  43. -webkit-transition-property
  44. -webkit-transition-timing-function
  45. -webkit-user-select

同等の接頭辞つきプロパティに紐づけられてサポートされるプロパティ

  1. -webkit-box-flex
  2. -webkit-box-ordinal-group
  3. -webkit-box-orient
  4. -webkit-box-align
  5. -webkit-box-pack

同等の接頭辞つきプロパティに紐づけられずにサポートされるプロパティ

  1. -webkit-text-fill-color
  2. -webkit-text-stroke-color
  3. -webkit-text-stroke-width
  4. -webkit-text-stroke

CSSグラデーション関係

  1. -webkit-linear-gradient()-webkit-radial-gradient()-webkit-repeating-linear-gradient()および-webkit-repeating-radial-gradient()の各関数は接頭辞なしの同等物に紐づけ
  2. 旧式の-webkit-gradientをサポートし、正規のグラデーションに変換

displayプロパティの値を変換

  1. -webkit-box-moz-boxに変換
  2. -webkit-flexflexに変換
  3. -webkit-inline-box-moz-inline-boxに変換
  4. -webkit-inline-flex-moz-inline-flexに変換

その他

  1. WebKitCSSMatrixインターフェイスをDOMMatrixの別名(エイリアス)として設定
  2. メディアクエリのメディア特性に-webkit-transform-3dを追加


(16/09/22追記)
本記事の掲載後、Firefox 49のリリースに合わせて、Firefox 49 fixes sites designed with WebKit in mind, and more ★ Mozilla Hacks – the Web developer blog(和訳:Webkit を念頭に作成されたサイトで起きるブラウザ互換性問題に対する Firefox の対応 | Mozilla Japan ブログ)が公開されている。

*1:該当するBugzilla@Mozillaのバグについては、mozilla.dev.platformのスレッド"Update on WebKit prefix support in Gecko."が詳しい。

Firefox 48でスマートロケーションバーのデザインが変更 元に戻す設定はなし

Fx情報

Firefox 48のリリースが目前に迫っている。このバージョンの目玉となるのがマルチプロセス機能(e10s)の有効化、Mozillaが推しているのがダウンロード保護の強化という事情もあって、あまり日が当たらないものの、使い勝手の観点からスマートロケーションバーのデザイン変更(Bug 1181078)は見逃せない。

f:id:Rockridge:20160803000355p:plain

Firefox 47までと見比べてみれば一目瞭然だ。これまで、ロケーションバーに文字を打ち込むと、ドロップダウンメニューに表示される候補はタイトルとURLの2行で表示されていた。Firefox 48の新デザインでは、これが1行にまとめて表示される。また、表示される候補の数が6個から10個へと増え(Bug 1195054)、各候補中の入力文字にヒットした箇所が太字で強調表示されるようになった(Bug 1273943)。

f:id:Rockridge:20160803001010p:plain

Beta版のリリースノートであっさりした記述になっていたためか、海外ではredditのスレッドにある程度コメントが集まっていたのに対し、国内ではかろうじて窓の杜が言及している程度だ。しかし、ロケーションバーを使用しないユーザーはかなり少数だろうし、ふつうは頻繁に使う機能のはずなので、リリース直後からそれなりに反響を呼んでもおかしくない。否定的な反響のほうが大きくなる可能性すらあるだろう。現に開発版の段階で、1行にまとめると見づらいとか、ドロップダウンメニューが大きすぎるといった批判が出ているからだ。

目立つ変更であっても、元に戻す設定がどこかに設けられていれば批判の矛先をかわすこともできるのだが、あいにく今回の変更は不可逆的なもので、設定で元に戻すことはできない。Australisが導入された際にClassic Theme Restorerが出たように、元のデザインに戻す拡張機能が出てこない限り、ユーザーとしては新デザインに慣れるしかない。

速報:Firefox 49本体からFirefox Helloが削除

Fx新着

Firefox 49本体からFirefox Helloが削除されたことが判明した(Bug 1287827)。Mozilla plans to remove Hello from Firefox 49 - gHacks Tech Newsで既報だが、該当バグのステータスはRESOLVED FIXEDとなっており、確定事項だ。米国時間の2016年7月19日時点で削除は決定されていたようだが、7月29日の午前3時過ぎまでBugzilla@Mozillaで秘匿指定がされていたため、情報が伏せられていた。

Firefox HelloはWebRTCの技術を利用してブラウザ内でビデオ(音声)通話を行うシステムで、相手方とWebページを共有して議論することに重点を置き、サインインなどの手続きがいらないという特徴を持つ。MozillaはスペインTelefónica社傘下の米TokBox社と提携し、Firefox Helloのプラットフォームとして同社のOpenTokを採用しており、その動作にはプラグインを必要としない。

2014年5月末にNightlyチャンネルでテストが始まり、ある時期までLoopのコード名で呼ばれていた。当初のコンセプトは、クロスプラットフォームな動画チャットアプリであり、ブラウザオンリーでWebRTCが有効なChromeやOperaとも通話できる点に目新しさがあった。デフォルトでツールバーにボタンが置かれるなど、Mozillaが一時期Firefox Helloを強く推していたのは間違いない。ユーザーからのフィードバックを受けて通話プロセスを簡略化したのも、利用を促進したいと思えばこそだ。

Firefox HelloはFirefox 35で正式にリリースされ、アクティブなタブまたはウィンドウの共有機能がFirefox 38.0.5で導入されている。Firefox 39では、ビデオ通話を開始するためのリンクを、本体に統合されたソーシャルサービスを通じて共有できるようになった

もっとも、MozillaはFirefox 45でFirefox Helloのコンセプトを変更した。現在のように「特定のWebページを互いに見ながら動画で通話する」ことを前面に出すようになったのだ。同時に、システムアドオンと呼ばれる特殊な拡張機能として提供されるようになり、アップデートの頻度が本体に縛られなくなった。最近では、マルチプロセス機能(e10s)にも対応し新ブランチも設けられていたので、開発が停滞していたとはいえない。

突然Firefox Helloが削除されることになった理由は、Bugzilla@Mozillaの該当バグを見てもわからず、推測するほかない。昨年からMozillaは、「Great or Dead(成功か死か)」を合い言葉に利用者の少ないプロジェクトを打ち切っており、今回もその一環と考えられる。前記gHacksの記事が指摘するように、同じシステムアドオンであるFlyWeb(クラウドを介さずにスマートフォンと電子機器が相互に接続できる仕組み)に人的リソースを回すつもりなのかもしれない。

削除されたFirefox Helloはどうなるのだろうか。既にある種の拡張機能の形式になっているので、少し手を入れてMozilla Add-ons(AMO)で公開ということも考えられるが、残念ながらその望みは薄い。なぜなら、ベースとなるOpenTokの利用が有償だからだ。Mozillaにとって終わりが見えている機能に対して支出を続けるのは難しい。仮にアドオンとしての存続があるとしても、時限的な措置となるだろう。

(16/08/08追記)
米国時間の8月3日、Firefox 49ベータ版のリリースノートにおいてFirefox Helloの廃止が発表された。これを受けて、Hello のサポートが Firefox 49 で終了します | Firefox ヘルプでは、Firefox Helloの代替サービスを紹介している。