たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能!
MicrosoftがEdgeの次期バージョンをChromiumベースにすると正式に発表した事を受けて発表されたMozillaの声明文について、自分が風邪やら何やらでゲンナリしている間にGoodbye, EdgeHTML (日本語訳) - Qiitaという訳が既に出ていたので激しく今更なのですが、自分でもえっちらおっちら訳してみたので、せっかくだから置いておきます。
さようなら、EdgeHTML
Microsoftは公式に、インターネット用の独立した共有のプラットフォームの維持を断念しました。Chromiumの採用により、Microsoftはオンライン生活の支配権をより一層Googleに譲り渡します。
これは実利と無関係の情緒的な話のように聞こえるかもしれませんが、そうではありません。「ブラウザエンジン」――GoogleのChromiumとMozillaのGecko Quantum――は、私達がオンラインで何をできるかの大部分を実質的に決定づける開発者向けのソフトウェア部品です。それらは、私達が消費者として目にする物、私達がコンテンツを見る時の安全性、Webサイトやサービスが私達に対して行う事(訳注:位置情報の取得、デスクトップ通知の表示、などの事か)をどれだけ制御できるかといった、基本的な能力を決定づけます。Microsoftの決定は、私達ユーザー個々人に何ができるかという事をベンダ側で一方的に決定してしまえる能力を、Googleに対してより多く与えるものです。
ビジネスの観点から、Microsoftの決定は充分に納得のいく物と言えます。Googleは私達のオンライン生活の基盤のコントロールをほぼ完全に握っており、この分野でGoogleに競合し続ける事はビジネス上有益ではないでしょう。私達に一度は与えられた自由と選択肢の提供を諦めたとしても、Microsoftの株主達の利益は保たれるでしょう。Googleは非常に多才なスタッフを雇用しユニークな資産を独占する、すさまじい競合相手です。Googleの検索・広告・スマートフォン・そしてデータ収集における横断的な支配力は、彼ら以外の残りのプレイヤーに対して大きく傾斜した、Google有利のプレイフィールドをもたらしています。
社会的、市民的、そして個人的な権利の観点から、基本的なオンラインの基盤のコントロールをたった1つの企業に譲り渡す事は、恐ろしい事です。これが、なぜMozillaが存在するかという理由です。私達は、ビジネス上の好機があるからGoogleに競合するのではありません。インターネットとオンライン生活の健全性というものが、競争と選択に依存するからです。それらは、一般の消費者自身がより良い物を求めて行動を起こす事を自己決定できる、という事に依存しています。
Microsoftの決定はFirefoxの繁栄をより困難にするでしょうか? おそらく、そうでしょう。Googleをより強力にする事は、様々な面で危険です。そしてその答えの大部分は、サービス・Webサイトを作ろうとするWeb開発者や業界・企業が何をするかに依存します。もしChromiumのような1つの製品が充分なマーケットシェアを持っているなら、Web開発者や業界・企業にとって、サービスやWebサイトがChromium以外のブラウザで動作するかどうか気にかけないでいる事が容易になるでしょう。それは、Firefoxがリリースされるより以前の、Microsoftが2000年代初頭にブラウザのシェアで寡占状態にあった時に起こった事です。そして、それはまた起こるでしょう。
もし<ruby>今日<rt>こんにち</rt></ruby>のオンライン生活で何が起こっているか気になるのであれば、Firefoxにも注意を払って下さい。Firefoxは18ヶ月前よりも劇的に改善されています――Firefoxは速度とパフォーマンスの点で再び引けを取らなくなっています。1週間ほど既定のブラウザとしてFirefoxを試してみて下さい、そしてそれから判断して下さい。Firefoxを強くする事がオンライン生活の問題のすべてを解決する訳ではありません――ブラウザは様々な要素の中のごく一部に過ぎません。しかし、もしFirefoxがあなたにとって良い製品だと気付いたら、あなたがFirefoxを使う事がFirefoxを強くします。あなたがFirefoxを使う事は、Web開発者と業界・企業がChrome以外の事を考える事を手助けします。そしてそれはFirefoxとMozillaがインターネット上の生活をより良くする手助けとなります――より多くの選択肢、より多くのセキュリティの選択肢、より多くの競争によって。
参考までに、本件についての日本語で書かれた記事へのリンクもいくつか示しておきます。
ロストテクノロジーAdvent Calendar要にXULRunnerの話を書いた直後に、Gecko自体ロストテクノロジーになっちゃうねこれっていう感じの発表があったというのは、何とも皮肉な話です。
This is a reply to the blog entry: Firefox Add-on Changes | Bill McCloskey's Blog
Hello, I'm the author of the listed addon Tree Style Tab.
You mean that we can rebuild Tree Style Tab with the sidebar API. However, I think that you don't find out what is the essence of TST.
I believe that TST's unique value is a natural compatibility for other tab-related addons, and sidebar API based TST loses the value.
If I rebuild TST using such a sidebar API, it can probably provide tree-like GUI in a sandboxed frame, working instead of Firefox's native tabs. But, probably other addons can't cooperate with it, because most addons' authors think about only their addons and Firefox's native tabs. Even if new TST became available based on the sidebar API which can't cooperate with other addons, it's useless. Moreover, then I'll receive more and more requests for the sidebared TST, like: Please add the feature provided by another something major tab-related addon, like "copy tab title"!
On the other hand, current TST changes just the appearance of Firefox's native tabs, so other tab related addons also work with it seamlessly even if they don't know TST. If an addon provide a new menuitem "copy tab title" in the context menu on tabs, it is also available even if TST is installed, because TST's "tree item" is truly Firefox's native tab. I mean that this is TST's natural compatibility for other addons. I think this value is never available with isolated addons based on sandboxed sidebar. Like the UNIX strategy, one addon should not include too much features, because one author only can do a few work. Instead, one addon should cooperate with others casually. I think this is why Firefox is loved by many power users.
The reason, why TST seems unstable and fragile, is that there are too less entry points for addons which work on Firefox's low level layer. Because we never can insert our custom operations to Firefox's features (like dragging of tabs, bookmarking of webpages, etc.), we have to replace it entirely or rewrite internal functions. If more stable entry points become available, TST will be more safe, stable, and compatible with other addons.
Anyway, my conclusion is: I believe that low-level extensibility for addons should be kept, even if new extension APIs become landed. Extensibility based only on isolated APIs will kill addons' casual cooperation.
Thanks.
One addition.
If addons based on new APIs can cooperate with others casually around Firefox's native features like current TST, I passively agree to the decision of killing low level extensibility for legacy addons. Basically Firefox should be more safe and stable for non-power users - I think so. If new APIs truly can build addons which cooperate with others seamlessly with enough rich entry points, then I'll have no reason to negate migration from legacy way to the new way - except that it is a hard work.
2年前のブラウザー勉強会で、FirefoxやThunderbirdの一括導入と企業での導入事例についての話をやったけど、その時に「こういう物を使ってます」と話だけ出した「メタインストーラ(FirefoxやThunderbirdのインストーラをキックしてサイレントインストールした上で、アドオンも一緒にインストールする物。設定を作り込んだ状態のFirefoxやThunderbirdを一括導入するために使う)」だけど、実はちょっと前からGitHubでひっそりと公開してた。導入案件の相談があってもリソース配分の関係で受けられないという事が何度かあったので、ツール公開しとくから自分でできる人は自分でやってねという話です。
が、過去の案件で要望が上がる度に場当たり的に機能追加や修正を繰り返してきて、それなのに目の前の導入案件をこなす事に手一杯でドキュメントが整備できてなかったせいで、公開したはいいけど結局弊社(というか僕)でないと使えない状態だった。ドキュメントを書こうと思っても、設定の仕方とかが煩雑ですっきり解説できないものだから、ドキュメント整備もなかなか進んでなかった。
それがこのところ、Mozilla関係の作業が少し落ち着いてて時間を確保しやすかったので、じゃあやるか!と頑張って、ドキュメント整備と設定方法の改善をちまちま進めてた(解説しにくかったのは実装が宜しくなかったからで、実装がすっきりしていれば解説もしやすいわけで、ドキュメントを書く事が契機となって実装が改善されるというのはよくある話なのです)。その締めくくりとして、簡単なチュートリアル込みの使い方解説エントリを会社のブログで公開した。アドオンを同梱して導入するだけのインストーラなら多分そんなに迷わないで作れるんじゃないかなと思う。
このFx Meta Installerは、FirefoxのWindows版インストーラと同じくNSISスクリプトで開発してるんだけど、思い返してみれば、僕のNSISとの付き合いはPortable Firefox(Firefox for Androidではなく、USBメモリで実行ファイルとプロファイルを持ち運ぶアレ)からだった。NSISはインストーラを作るための物なんだけど、使いよう次第ではPortable Firefoxみたいなこと(プロファイルをテンポラリフォルダにコピーして、Firefoxを起動して、Firefoxが終了したらプロファイルをUSBメモリに書き戻す)もできる。ずーっと前にMozilla Japanが秋葉原と渋谷でFirefoxの入ったCD-ROMを配るというプロモーションをやった事があったけど、あの時配ってたCDの「ディスクを入れたらautorunでFirefoxがお試し用に起動する」っていうやつは、実は、Portable Firefoxを改造したか参考にしたかして僕が作ってたのですよね。それがなかったら今のFx Meta Installerはなかったかもしれないと思うと、ちょっと感慨深い。
あと、Fx Meta Installerの設定項目だったり機能だったりを見てると、ああこんな事もあったなあ……と過去の案件の事を色々思い出させられる。Linuxでもビルドできるようにしたのは、普段使ってるUbuntu入りのLet's noteだけ持ってお客さんの所で動作を試して直してビルドしてまた試して……というのをやるためだったし、解説エントリでは触れてないけど、メタインストーラのバイナリに電子署名するための設定を見てると、グローバルサインで証明書を買う手続きをしたなあという事を思い出すし。いまFx Meta Installerに実装されてる機能は、お客さんの要望だったり状況だったりの必要に迫られて追加したものがほとんどなので、ある意味でこいつは僕の仕事(の1つ)の履歴そのものとも言えるのかもしれない。
Firefoxのプロセス分離モデルへの移行は当面行われないことになったのだそうだ。Firefox Hacks Rebootedでe10sでの開発の方法について色々書いたばかり(いや実際にその節を書いたのはずっと前なんだけど本が出たのはつい最近の事だったのですよ)なのに!
デスクトップ版Firefoxでe10sが使われないとなると、今e10sが使われてるのはFirefox Mobile(Fennec)だけということになる。そのFirefox MobileもそのうちXULを捨ててAndroidネイティブなアプリケーションとして作り直すという話もあって、そうすると本格的にe10sはオワコンっていう事になってしまう。
そうなると気になるのが、Add-on SDKだ。今のAdd-on SDKはe10sを前提に諸々のAPIが作られていたはずで、e10s前提にしないといけないからこそ、かなりめんどくさいAPIになっていたという印象がある。それが、そもそもe10sいらなくなっちゃうんだったら、後に残るのは単に使いにくいAPIだけって事になってしまう。また、仮にe10sを前提としないAPIに作り直すんだとしたら、それは「APIの互換性を保ち続ける」と言っていたAdd-on SDKの売り文句を自分で否定する事になるわけで。にっちもさっちもいかなくなって、Add-on SDKの開発をやってたチームはほんと涙目ですね。
それはそうと、中野さんはe10sには個人的に反対(マルチプロセスよりマルチスレッドだろ派)していて今回の決定は歓迎だと仰っているけれども、Geckoより上のレイヤでしか開発を行わない人間にとっては、マルチプロセスだろうがマルチスレッドだろうがあんまり変わらない(どっちにしても今より面倒になる事には変わりない)ので、「e10sオワタ! やった!!」とか喜ぶような話でもないんですよね。
というのも、今のFirefoxではbrowser要素のdocShellからcontentDocumentとか辿っていってWebページのDOMに普通にアクセスできてっていう感じの事ができるけれども、コンテンツ領域がマルチスレッドなりマルチプロセスなりになれば、結局今のやり方は通用しなくなってしまうわけです。マルチプロセス(e10s)でもマルチスレッド(例えばWorker)でも、プロセス間・スレッド間での通信にはせいぜい文字列形式のメッセージしかやりとりしかできないので、仮にコンテンツ領域がマルチスレッド化されたとしたら、コンテンツ領域との情報のやりとりは結局やっぱりe10sのmessageManager周りのAPIと同じようなAPIにならざるを得ないのですよね。今の、WebページのDOMにChrome領域のスクリプトから触り放題な設計は、いずれにせよそのうちオワコンになっちゃうのでしょう。
オチはありません。
既にご存じの方もいらっしゃるかとは思いますが、オライリーから「Firefox Hacks Rebooted」という本が出ました。3年前に出た「Firefox 3 Hacks」の続き……でもないのですが、似たようなコンセプトで「今」の話をまとめた本です。
本1冊を通して1つのストーリーに基づいて何かを体系立てて解説する、という本ではなくて、各著者が自分の得意分野で好きなように書きたい事を書きまくった本、というのが実情を正しく言い表している気がします(元々、オライリーの「○○ Hacks」というタイトルは「なんでもあり」のブランドなんだそうで……その言葉に甘えてしまいました)。
以下、各章の対象読者層と思われる層、内容の簡単な紹介と、定量的に傾向を把握するための手がかりとしてページ数と全体に対する割合を表にしてみました。これを見ると一発で分かりますが、僕(4章と6章の一部を担当)の暴走が著しいですね。やばい。
章 | 主な対象読者層 | 内容 | ページ数 | 全体の中でのパーセンテージ |
---|---|---|---|---|
1章 | エンドユーザ | Firefoxの新機能紹介など基本的な事。Firefox 3.6とFirefox 4以降との間で何が変わったのかのまとめ。 | 54 | 11% |
2章 | 開発者寄りのユーザ | VimperatorとKeySnailの解説。と、Twitter用アドオンの解説。ブラウザとしてのFirefoxをガンガン使いこなしていく人向け。 | 42 | 9% |
3章 | アドオン開発者 | Add-on SDKを使ったアドオン開発のチュートリアル。アドオンの開発をこれから始めたいという人向け。 | 68 | 14% |
4章 | アドオン開発経験者 | Bootstrapped Extensions、ChromeWorker、e10sなど、Add-on SDKよりも下のレイヤの技術の解説。今既にアドオンを開発してるという人や、Add-on SDKではできない・標準ライブラリでカバーされてない範囲の事に手を出そうと思ってる人向け。 | 156 | 33% |
5章 | Webデベロッパー | Firefoxで利用できるHTML5関連技術やECMAScriptの紹介。Webデベロッパー(主にフロントエンド)向け。 | 98 | 21% |
6章 | アドオン開発経験者、Webデベロッパー | ハードウェア寄りの話と、その他のこぼれ話。アドオンやWebアプリの開発で、ネイティブアプリ並の事をやりたい人向けの話が多め。かも。 | 56 | 12% |
自分の担当箇所だけ細かく見てみると、ページ数と全体に対する割合はこんな感じです。
調子に乗って脳汁ドバドバ出して書きまくる→ページ数が増える→値段上がる→損益分岐点も上がる という危険なコンボが発動してしまったためかお値段高めとなっておりますが、自分の担当箇所も他の方の担当箇所もひっくるめて、腰を据えて読むに値する情報ばかりなんじゃないかなーと思っております。Webで難なく読める文章の長さと、(紙でも電子でも)書籍の形になってた方が読みやすい文章の長さって、やっぱり違うと思いますしね。
本書のサポートサイトも公開されており、正誤表や本文中の各コードリストのダウンロード、本文の一部を切り出したサンプルPDFの無償公開などがあります。正誤表等はこれから更新されていくと思いますので、本書をお読みになられる際はこちらのサイトも併せてご参照いただければ幸いです。
以下は、思い出話です。
本書の企画がスタートしたのは、Firefox 4の正式版が出る前の2010年5月頃だったと思います(今メールボックスの一番古いメールの日付を見て確認した)。当時はまだ内部バージョンがFirefox 3.7とか言われていた頃で、Aero Glassが標準で入るのか?とか、そんな事を言ってた時期でした(という事も今Wikipediaを見て確認した)。
それからしばらく、どんな内容にするのがいいか? どんな人に執筆を依頼しようか?(今著者の一覧に名前が載ってる方の中には、最初の時点で名前が挙がってた著者の側から「是非この人にも書いてもらいたい!」と引っ張り込んだ人もいるのです) という事を話し合っていて、執筆者が確定したのが8月。そこからぼちぼち書き始めて、なんやかやで1年経ってしまいました(普通はここまで難産にはならないみたいです)。その間にFirefoxのバージョン番号もどんどん上がっていって、もうすぐFirefox 8ですよ奥さん! 時間が過ぎるのは本当に早いものですね。
最初の頃は、自分は「Firefox 3 Hacksで書いた内容をFriefox 4時点での情報に基づいてリライトするか?」程度の事を考えていました。でも、それじゃあ書いてる自分がつまらないし、それこそすぐに陳腐化してしまいます。それでうんうん唸りながら調べていくうちに、Firefox 4以降の話で新しい基盤の技術になりそうなトピックがいくつかあるという事が分かってきたので、それじゃあってんで、そこをターゲットにして書いていく事にしました。実は、自分の担当箇所は半年くらい前にほぼ完成してたんですよね。そこから本書の発売までの間は、(他の事に時間を使ってたからというのもありますが、)細かい記述のアップデート程度しかやってません。高速リリースになってからガンガン方針が変わったり実装が変わったりしてて、本書に書いた「テクニック」の中にも、既に「もうこんな回りくどい事しなくてもいいんだけどなぁ」な感じになってしまった話題がいくつかあるにはあるのですが(校正の詰めの詰めに入った段階でまたどどっと変更が入ってきて、どーしても間に合わなかったんです……)、全体としてはちゃんと今でも、そしてこれからも通用する話になってると思います。あの時の自分の目の付け所は、そんなには間違ってなかった、はず。
紆余曲折があった末にようやく世に出る事ができた本書ですが、アドオン開発者の方の手助けとなり、また、アドオン開発に手を出してみようと考えている方の手引きとなれば、幸いです。
他の著者の方々による本書の紹介のエントリ:
Back to Owner Tabを公開したよという話を書いた時にそもそも勝手に新しいタブを開かないようにしたいという意見のトラックバックがあった。そこのコメント欄で「なんでブラウザがそういう機能を提供してくれてないのさ」って議論になってた。
それでふと思い出したんだけど、そういえば昔のMozillaにはtarget属性の指定を無視して現在のタブでリンクを開く機能がなかったっけ? 削除されたのかな? と思って調べてみたら、自分でもすっかり存在を忘れてたけどこの機能はFirefox 4でも健在で、隠し設定としてちゃんと生き残っていた。about:configを開いて「browser.link.open_newwindow」を「1」に変更すれば、target属性によって新しいウィンドウやタブを開くように指定されているリンクでも、普通のリンクと同じように元のページを置き換える形で遷移するようになる。(この機能が入る前に「新しいウィンドウを開くリンク」の挙動を置き換えようとして、旧タブブラウザ拡張では相当な無茶をやっておりました。懐かしい話です。)
実は、Firefoxの設定ダイアログで「新しいウィンドウではなく新しいタブで開く」っていうチェックボックスを切り替えると、この設定の値が「2(新規ウィンドウで開く)」と「3(新規タブで開く)」でトグルするようになってる。「1(現在のタブで開く)」は普通に設定ダイアログを使ってたら選択できないので、about:configか何か別の手段を使わないといけないというわけ。
変更履歴をどんどん遡っていってみたところ、ごく初期の設定ダイアログでは確かに3つの選択肢から1つを選ぶようなUIになってたんだけど、これがFirefox 2でprefwindowベースの設定ダイアログに置き換えられた時に、しれっと「新しいウィンドウで開く」と「新しいタブで開く」の2者択一になってた(現在のタブで開くという選択肢が消えていた)。その時の議論には特に情報はなかったんだけど、「新しいウィンドウで開く」と「新しいタブで開く」の2者択一のUIから今のチェックボックス型UIに変わった時のバグの方を見てみると、まさに前述のエントリで述べられているような議論が繰り広げられていた。
で、ざっと見た感じでは、 「リンクのtarget属性とそれ以外の場合のために2つも設定項目作る意味なくね? 1個でいいんじゃね?」→ 「そもそもなんでUIから1を選択できるようになってないんだ?」→ 「破壊的な挙動になるオプションだから敢えて選択できないようにしたんだよ。」 「そのオプションを選択してたらクラッシュしたこともあったしね。」 「実際、open_newwindow=1に設定するとかなりのWebサイトがぶっ壊れるよ。そりゃウィンドウなんて開くべきじゃないのはみんな分かってるけど、ユーザを混乱させないためにはIEと互換性のある挙動にしとかないと。」→ 「JavaScriptで開かれるウィンドウについてはopen_newwindow=1にしたら色々危ないのは分かるけど、リンクのtarget属性だったら無視しても問題ないでしょ?」→ 「どうしてもアドオン無しでやりたいならこういう方法もあるよ。」
という感じで、
という結論に至った……みたいだ。
ということで、すっかり忘れてた&調べ直してて改めて思い出したわけだけれども、browser.link.open_newwindowを1にすると、target属性があるリンクだけでなく、window.open()
の読み込み先も現在のタブになってしまうために、親ウィンドウを参照するようなスクリプトが含まれてるページはまともに動かなくなる恐れがあるので、これはお薦めできません。トラブル覚悟でこの設定を使ってもいいけど、target属性があるリンクだけ同じタブで開くようにしたいという場合には、そういう機能を提供するアドオンを使うなり何なりしないといけないよーです。
まあ、いろんな場合に対して細かく挙動を振り分けたいという人は既に(当時の)Mozillaが考える所のメインターゲットではなかったのでした、そういう人は自分がマイノリティであることを自覚してDIYの精神で暮らすしかないですね、という話なのでした。
CSS Transitionsではアニメーションの終了時にtransitionendというイベント(webkitではwebkitTransitionEnd)が発行される事になってて、Minefieldに既に入ってる「タブを開く時にアニメーションする」「タブを閉じる時にアニメーションする」という機能でもこれが使われてる。具体的には、max-widthをアニメーションさせることでタブがぬるっと生えてきたりぬるっと縮んでいったりという効果を与えて、アニメーションが終わった後で実際にタブの要素を削除するという風な事が行われている。
このtransitionendイベントがたまに発行されない事があって、そのせいで「閉じたはずなのにタブがそのまま残ってしまう」「タブが開かれた後に行われるはずの処理が行われない」といった問題が発生していた。特に、ツリー型タブではタブバーの向きを横長ではなく縦長に変更していて、その絡みでmax-widthのアニメーションの代わりにmax-heightとかmargin-topとかopacityとかをアニメーションさせるようにしてるんだけど、そのように複数のプロパティについて異なるdurationでアニメーションを行うようにしてる時にこの問題が顕著に発生するようで、しかし確実に問題を再現させる条件がはっきりと分かっておらず、Bugzillaに報告しようにも報告できない状態が長く続いてた。
それが今回、ひょんな事から確実に問題が再現する条件を特定できたので、Bugzillaに既に存在していたBug 613888 – Sometimes transitionend doesn't fireに再現性100%のテストケースを投稿してみた。
そしたら、そこからの動きが早かった。タイトルが示すように「時々しか起こらない」ということで割と優先度低めの扱いだったっぽいのが、hardblockerになってblocking2.0になって(つまりこのバグが直らなきゃFirefox 4はリリースされないという致命的なバグと認識された)、David Baronさんがパッチを書いてくれて、ついでに僕の投稿したテストケースを元にした自動テストもパッチに含めてくれて、あとはレビューとチェックイン待ちという状態になっている。
べつに僕が最初に問題を見つけた訳ではないし、僕が実際にパッチを書いたわけでもないけれども、自分のやったことがきっかけになって厄介なバグが修正に至ったと思うと、率直に言って「やったぜ!!!」と自分の事のように嬉しく感じてる。
このエントリで何を言いたかったのかというと、要するにその「やったぜ」の自慢話ということなんだけど、それと同時に、再現性100%のテストケースや再現手順を特定することは大事なんだよ、それを自動化することも大事なんだよという事も伝えたかったのです。
再現性100%の手順が判明していればすぐに開発者の環境でデバッグできるし、自動テストがあればそれをそのままリポジトリに取り込むこともできる(=今後のregressionの発生を予防できる)。パッチを書けない人でも書けないなりの協力はできるのです。単に「動かないよ」と言うだけの場合よりも、原因特定のための検証を開発者がやる手間が省けるから、効率がいいしバグも早く直る訳です。
というわけで、バグ報告には確実に問題を再現できる手順(できれば自動テスト)を添えて下さいね、という話なのでした。
16日追記。パッチがチェックインされた後のナイトリービルドで、自分の環境では上記の問題が解消されていることを確認できた。よかった……これで安心してFirefox 4を迎えられるよ。
背景。
Web標準に対応しなくて自社独自の技術だけ使い続ける、というのはまあよくある事だから、ことさらMozillaだけをあげつらう事はないと思うんですよ。VMLには対応するけどSVGには対応しないというIE8までの方針であるとか、そういうのはありふれてる。
また、標準仕様はあるけどまだ実装されてない、っていうのもしょうがないと思うんですよ。仕様そのものが曖昧だとか、仕様が膨大すぎて対応できないとか、需要がそもそも無いとか。
釈然としないのは、
これが僕には2枚舌に見えるってこと。
APNGに新たに対応して今後はそっちをメインで使っていくよ、というのはまあ別にいいんですよ。でも、今まで一応対応してたMNGをこれを機にばっさり切り捨てちゃう今まで一度は対応してたことがあったMNGを顧みることもなく別の物をっていうのはどうなん? それじゃあ、なんかの動画形式で動画を埋め込んでて、その形式に対応してなかったらMNGにフォールバックして、みたいな事ができなくなっちゃうじゃんできないまんまじゃん? フォールバック先にはやっぱり、仕様が標準化されてて安心して使える形式を選びたいじゃん? そういう感じでMNGを使ってた使いたい人がいたかもしんないじゃん? 僕はまだ使ってなかったけど、静止画の簡単なアニメーションを公開する事があったら是非そうしたかった。Web標準ってそうやって、地ならしっていうか下支えっていうかそういう所でも活きてくる物だと思ってたんですよ。
いやMozillaの言い分もわかるっちゃ分かるんですよ?
「MozillaはWeb標準を限定的にしか尊重しません。自分たちの組織を維持できなくなるレベルでコミットする事はありません。自己犠牲でWeb標準のために殉死するつもりはさらさら無いです。」というのは真っ当な判断だと思うんですよ。
でも、だったら、「お前はWeb標準を大事にしてない」って他者を非難する資格も無いんじゃないの? 自分の事は棚に上げるの? そういうみっともない事をしないでくれよ。Mozillaだけはそういう事をしてくれるなよ。
っていうモヤモヤがずっとある。
かつてIE6が一番先進的なブラウザだった頃は、ブラウザに機能を加える物といったら、「ツールバー」か「コンテキストメニューの追加項目」くらいしかなかった気がする。そもそも、「ブラウザにツールバーを追加できますよ」だけでもずいぶんすごいことであったような気がする。僕がそれ以外を知らなかっただけかも知れないけど。(具体的に僕が「その頃」の代表的なブラウザとして今思い浮かべているのはIE6とNetscape Communicator 4.xです。)
その頃は、MicrosoftとかNetscapeとかがリリースしてるメジャーなブラウザの使い勝手に不満があっても、プログラミングの知識がないフツーの人は、我慢するか、既にある別のブラウザ(iCabとかOperaとか)を探すかしか無かった。そもそもこの時代、ちょっと前までブラウザは4000円とか9000円とかお金払って「買う物」であったから、基本的には「買った物をそのまま使うか、買わないか」という選択肢しかなかったとも言える。
それでも、腕に覚えのある人なら、コアであるレンダリングエンジンにはIEの物を流用して、それ以外のブラウザのUI自体を頑張って全部作り直すということは可能だったようだ。それで出てきたのがDonutだったりSleipnirだったりLunascapeだったりのいわゆるIEコンポーネントブラウザだった。メジャーなブラウザがリリース計画とか顧客とか組織とか色んな都合で足踏みしている間に、個人の開発者あるいは小規模な開発チームであるが故のフットワークの軽さによって、凡庸なメジャー製品では手に入らなかった「痒い所に手が届く使い勝手の良さ」を提供したことで、それらIEコンポーネントブラウザはパワーユーザの支持を得るに至ったのだろう。
IEを使うのなら、できる「機能拡張」はせいぜいツールバーの追加かコンテキストメニューの機能追加くらい。なぜなら、IEが開発者向けに開いていた「ブラウザの個々に機能を追加できますよ」というポイントが限られていたから。(あるいは、もっと色々できたのかもしれないけど、それくらいしかできないという印象が強かった。)それ以上の物が欲しかったら、そういう機能を提供するIEコンポーネントブラウザに乗り換えるしかない。それが、あの頃に取り得た現実的な選択肢の全てだったのだと思う。
僕にとっては、そういう「暗黒時代」はMozillaとの出会いで終わった。当時はまだMozilla Suite(Seamonkey)がメインラインで、バージョンはM16とか0.6とか言われてた頃だったか。当初はCSS2に一番真っ当に対応してたブラウザだったからという理由で使い始めたけど、使い続ける理由はいつの間にか、「一番痒い所に手が届くから」になっていた。
Ben Goodger氏が当時を振り返って語ったエントリにもあるけれど、Mozillaの設計上の特性からくる「拡張性の高さ」はホントにぶっ飛んでた。
Mozilla以前は、
「標準のUIに不満がある? Googleサジェストが使える検索ボックスが欲しい? じゃあ、このツールバーを追加して下さい。ほら、このツールバーの中でならもっと快適に過ごせますよ! Googleサジェストの結果もポップアップされますよ! まあ、このツールバーの世界から一歩でも外に出ると、また今まで通りの世界に逆戻りですけどね。」
「え、このボタンだけ切り離してウィンドウの下の方に置いておきたい? そんなことできるわけないでしょ。この素敵な便利機能は、このツールバーの世界から外には持ち出せませないんですよ。」
「え、専用のツールバーなんかいらないから、本来のアドレスバーから色んな検索エンジンでWeb検索できるようにしてくれって? そりゃ無理ですよ。このツールバーの枠の中の事ならどうとでもできるけど、枠の外は元々作られてた通りにしか動かないんだもの。」
こうだった。ツールバーという細長い箱の中、コンテキストメニューというメニューの中、そういう様式の中でないと何もできなかったっぽかった。
あるいは、こうだった。
「このブラウザに乗り換えたら、こんな便利な機能が使えますよ!」
「え、こっちのブラウザのこの機能が欲しいって? そんなこと言われても、それは別のソフトだし……正直、そんなもん知らんがな。」
「パソコン盗まれてソースコードが失なわれちゃいました! もうメンテナンスできません!」
でもMozillaではそうじゃなかった。
「標準のUIに不満がある? じゃあ、そこをピンポイントで解決しちゃえばいいよ。」
「ボタンはウィンドウの上じゃなくて下の方にあって欲しい? じゃあそうすればいいよ。ほら、ツールバーのボタンをウィンドウの下に移動できるようになった。」
「アドレスバーから色んな検索エンジンで検索できるようにしたい? じゃあそうすればいいよ。ほら、GoogleやAmazonの検索結果がアドレスバーの履歴と一緒に表示されるようになった。」
こうだ。実にシンプルだった。「イラッ」と来たまさにその点を、イメージしていた通りに、一番ストレスのない形で解決できる。ツールバーという細長い四角い枠の中であるとか、たった1人の作者の都合であるとかに、囲い込まれなくてよかった。使いたい機能を使いたいように組み合わせて使えた。
具体的な例をもっと挙げると、例えば、ツリー型タブとマルチプルタブハンドラと情報化タブの併用みたいなことができるのかどうか、ってことなんですよ。
タブで開いてるページをツリー表示するポップアップを表示する拡張機能。うん、それは多分便利。
開いてるタブのリストを表示して、任意のアイテムを選択してまとめて操作するポップアップを表示する拡張機能。うん、それも多分便利。
開いてる全てのタブの内容をサムネイルで一覧表示するポップアップを表示する拡張機能。うん、それも多分便利。
で、それを1つにまとめて同時に使えるの? ツリー表示されていて、気が向いたらそれを複数個選択してまとめて閉じられて、それらには常時サムネイルが表示されてる、というソリューションは誰でも得られるの? エンドユーザでも? って事なんですよ。
「ツリー表示してサムネイルも表示して複数選択もできるUI、を提供する1つの拡張機能」があればいい? 「ツリー表示してサムネイルも表示して複数選択もできるUI、を持ったIEコンポーネントブラウザ」があればいい? そういう物がもしあるのならそれを使うのもいいだろうし、作れる能力があるのなら作って全然いいと思う。でも、そういう物が無かったらどうなのか? 誰も作っていなかったら? そして自分でそれを作る知識は無いというのなら?
また、3つの機能を持った物くらいならともかく、要求事項が4つ5つと増えていったらどうなるか。条件が増えれば増えるほど、既製品で要求を完全に満たす物は見つけにくくなるだろう。妥協が増えてくるだろう。その逆に、個々の要求事項を満たす物を集めてきてそれで1つの物として使えるのなら、何も我慢しなくて済む。
だから僕は、Firefoxを捨てられないんだ。「Operaならあれもできるよ、これもできるよ」って言われても、「Chromeなら爆速だよ」って言われても、「ほうほう、ではこのポップアップパネルの下の端にこれこれこういうボタンを置いておきたいんだけど、そういうことはできるのかね? え、できない? ああそう……それじゃ日々の『イラッ』はなくならないなあ」と思ってしまうんだな。(だからFirefoxが好きなんですよ、っていうのが全く無いとは言い切れないけど、むしろ、他の物もそうだったらいいのに、でも残念ながらそうじゃないから諦めてFirefox使い続けるしかないのか、って思ってる所も結構ある。)
でも、時代は今また「用意された枠の中でならなんでもできますよ、でもそこからは一歩もはみ出せませんよ」の方向に戻ろうとしている。(いや、あの頃に比べたらずっと洗練されたAPIで、できることの幅も広がっているようなのだけれども。)何故なのか。
理由はたくさんあるようだけど、多分一番重要なのは、「みんな、そんなに自由でなくていい」って事なんだろうね。
頑固で融通の利かない馬鹿で順応性が低い僕にとっては、こうだ。「イラッと来たまさにその部分がピンポイントで解決されてくれないと、我慢ならない。ちょっとでも遠回りしないといけないのは、もう嫌。このツールバーの中でならそんな不満は起こりませんよ、なんて言われても、ツールバーなんていらんし。そんなん興味ない。今目の前にあるコイツがどうにかなってくれないと嫌なの。」でも、普通の人は僕なんかよりもっと頭が柔らかくて順応性が高いから、苦にならないんだろう。「こういうとこが不満で、なんとかして欲しいんだけど。え、代わりにこれを使わないといけないの? ふーん、まあ、いいけど。」で受け入れてしまえるのだろう。
(というか多分そもそも「こういうとこが不満で」なんて思わなくて、今ある物でだいたい満足できてしまうんだろう。思い入れも無ければ、一日中それと接するわけでもない、1日1回1時間くらいしかブラウザを操作しない、だからそんな深刻な不満を抱きようがないんじゃあないかな。頭が固いとか柔らかいとか以前に。)
(あと、これは、「普通の人」を揶揄する話ではない。そういう人達の方が環境の変化に柔軟に適応できる能力があるって事で、それは人として素晴らしいことだと僕は思う。こうやりたいと決めたやり方以外だとストレスを感じてしまうとか、そういうどうでもいいことにこだわってしまう性根というのは、人として問題があると思う。)
Jetpackがrebootされる前、まだJavaScriptのファイルいっこで完結してた頃、僕は「JetpackはGreasemonkeyやChromeの拡張機能とAPIのレベルで互換性を設けるべきだ」と強く思っていた。なので今回のOperaの「拡張機能を標準化しよう」っていう話に僕は賛成する。既に、ChromeとSafariの間では既にそういう状況になっていると聞いた気がする。大抵の人がそれで満足できる、ツールバーのボタンなり、Webページ内で自動実行されるスクリプトなり、そういう「どのブラウザでも共通して利用できそうな物」には、互換性があっていいと思う。僕だってひょっとしたら、ユーザになるかもしれないし。OperaやSafariをメインで使ってる人が作った拡張機能の恩恵に僕がFirefoxで与れる、そういうことがあり得るかも知れないし。
ただ、Firefoxと同じくらいになんでもできる環境になってくれない限りは、僕自身は軸足をChromeとかその後に出てくる物とかには移せないんじゃないかなー、と思ってる。些細な「イラッ」に目を瞑らずにストレートにそれを解消することができる、という居心地の良さに、僕はあまりにドップリと浸かりきってしまっているので。あまりに「自分を変えなくていい」事に慣れきってしまっているので。
この間悩まされたばかりのomnijarの話である、Taras’ Blog » Blog Archive » Firefox 4: jar jar jarの勝手翻訳です。分からない所が多かったので創作的意訳が多めですが気にしません。
ファイルを開く処理というものは、システムコールのための小さなオーバーヘッドや、ディスクからのデータの先読みによる大きなオーバーヘッドがある、比較的重たい処理です。データの物理的な配置の状態やディスクの種類によっては、この処理は今時の高速なCPUに対して、複数の異なるファイルそれぞれの全ての断片を先読みするためにディスク上をヘッドが激しく行き来する間、長々と無駄に暇をもてあまさせる事にもなり得ます。
約2年前、私(訳注:元エントリの著者のTaras Glek)はディスク上にある裸のファイルを収集してjarファイルに詰め込む作業を始めました(例:bug 508421)。また、コードのクリーンアップやmmapへの移行などを通じて、私達はjarファイルの読み込み処理の効率も可能な限り改善しました。そして最終的には、通常の起動時にディスクから読み込まれていた、アプリケーションを構成するデータファイルの全てが、jarファイルの中に格納されるようになりました。しかし残念ながら、私達は4つのjarファイル(toolkit、chrome、そして2つのロケール用jarファイル)に構成ファイルをまとめる所までしか至れませんでした−−何ともマヌケな事ですけれども。またXPCOMの制限により、多数の裸のファイルがまだ、Firefoxのアップデートや拡張機能のインストールの度にディスクから読み込まれる状態となっていました。
最近、Michael Wuがomnijarという<ruby><rb>滅茶苦茶にヤバい物を解き放ち</rb><rp>(</rp><rt>非常に影響範囲の大きな変更を導入し</rt><rp>)</rp></ruby>ました。これはAndroid用パッケージ作成での必要に迫られて行われた非常に大きな取り組みです。今や、アプリケーション起動時に必要なデータは常に単一のファイルから読み込まれるようになりました。これはデータの位置の集約化、ファイル走査の手間の短縮、そして待ち時間の短縮に繋がります。複数のファイルを1つに小さくまとめる事の1つの利点としては、OSがディスクからデータを読み込む際に、大抵の場合はアプリケーションが要求したよりも大きな単位で、投機的にディスクからデータを読み込む事も挙げられます。これにより、隣接するファイルの読み込みがより自由に行えるようになります。残念ながら、Firefoxを実際に実行せずにファイルアクセスの順番を予測するための良い方法がなかったため、ここにはさらなる改善の余地があります。
さて、今や全てのデータが1つのファイルの中に置かれましたので、論理的な次のステップは、それらをより賢く格納する事でした。それを行うための唯一の方法は、Firefoxの起動時の処理を分析して、jarファイル内のファイル配置をその結果に基づいて並べ替える事です。残念な事に、jarファイル内の全ての項目を連続的に配置するにあたって、私達はまだ次善の策を取っています。これは、ZIP(jarファイルの実態はZIPファイルです)のインデックスが伝統的にファイルの終端に配置されている事に依っています。Wikipediaの記事にこれを図示した物があります。
先読みの利点を最大限に活かし、ディスクの走査を最小限にするためには、格納されたファイルのインデックスがZIPファイルの先頭に置かれているのが望ましいです。そのため、私は私達のZIPファイル内のデータの配置を、
<項目1><項目2>…<項目N><インデックス><インデックスの終端>
から
<最初に読み込まれる、最後の項目の位置のオフセット値><インデックス><インデックスの終端><項目1><項目2>…<項目N><インデックスの終端>
に変更しました。
ここで私がやったのは、<インデックスの終端>のオフセット値を常に4になるようにした(どうでもいい事に拘るZIPアーカイバはインデックスのオフセットがNULLだとフリーズしてしまう事があるので、これは0にすることはできません)だけです。その際、インデックスは常に前のインデックスの終端に続けて配置されなければならないという仕様を満たすために、私は最初の物と全く同じ2つ目の<インデックスの終端>を加えました。また、私は、過度に用心深いZIPアーカイバによって強制された、どれだけのデータを最初に先読みしておく事ができるかを示す数値を格納するための追加の余白も利用する事にしました。
これによって、最適化されていないomnijarに比べてディスクI/Oの2〜3倍の削減を実現しました。これは裸のファイルをomnijarにすることで20〜100倍以上の高速化が実現できた事の最大の要因です。
私がZIPの仕様を読んでガッカリしたのは、ZIPアーカイバの中にはZIPファイルが仕様が許容しているよりもずっと厳格な形式になっている事を期待している物があるということです。以前のバージョンのFirefoxや、Microsoft WindowsのZIPサポート(訳注:圧縮フォルダ)、WinRAR、UNIXのZIPアーカイバなどは、私の最適化されたjarファイルを受け付けてくれますが、7-Zipや壊れたアンチウィルスソフト(スキャン対象を無闇矢鱈に限定する事はセキュリティ上危険です)はこれらを開く事ができません。
豆知識:これは、受け付けるZIPファイルの内容を選り好みするソフトウェアのせいで困らされた最初のケースではありません。例えば、Android標準のAPK読み込み処理は、Android用のパッケージが0バイトの大きさの項目を含んだZIPファイルである場合に、いちいちしつこくそれを警告してきます。これは、APK形式のファイルをWindowsにおける自己解凍形式のEXEファイルのように使う事ができないということです。Michael Wuはこの問題を解決するための独自の読み込み用ライブラリを書いている所です。
omnijarは十分に素晴らしいとはまだ言えないということで、Michael Wuはさらに先に進んで拡張機能をomnijar化しました(訳注:アドオンがXPIのままで認識されるようになった事を述べたエントリ)。ほとんどの拡張機能はXPIから裸のファイルに展開される必要が無くなる事でしょう。これは、拡張機能の作者が上記のような最適化されたjar形式を、Firefoxの起動を高速化するために利用できるという事を意味します。
起動処理の高速化用のキャッシュをjarに切り替える事によって、私達は最初の起動処理をさらに最適化できるようになることでしょう。私が最適化されたjarファイルに加えた先読み用の情報を実際に利用する事によって、jarファイルのI/Oを半減できる可能性もあります。
2点だけ:
1つ目。あなたがどのように言おうと、これらの「最適化された」jarファイルはもはやZIPファイルではありません。仕様は非常に明確で、インデックスはファイルの末尾になくてはなりません。
あなたがやった事に間違った点はありませんが、しかし、それらのファイルをZIPであるかのように偽ろうとした上で、ZIPを扱うアプリケーションがそれらに対して文句を言わないようになる事を望むというのは、良い事ではありません。それよりもあなたは、最適化されたファイルの拡張子を変更することにして、最適化とその解除を手動で行うためのツールを提供した方がよいでしょう。
私は、例えば7-Zipは仕様に対して非常に厳格に設計されているがために、これらのファイル形式をサポートする事はあり得ないだろうと確信しています。
2つ目。私はFirefoxのコールドスタート(訳注:キャッシュ等にファイルが読み込まれていない状態からの起動)が(特に他のブラウザと比べて)遅いということを体感して、少し調べてみる事にしました。新規作成したプロファイルであってもまだ起動は遅かったです。私は、Firefoxは起動時に18個ものDLL(それらは全て、Firefox/Minefieldのインストール先ディレクトリに置かれています)を読み込んでいるという事に気がつきました。これは非常に良くない事で、ファイルの数の問題だけでなく、Windowsではセキュリティ対策ソフト(既定の状態であればWindows Defender、大抵の場合は何らかのアンチウィルスソフト)においての問題もあります。
私のマシン上では、ファイルのスキャンは1つあたりだいたい50ミリ秒を要していますが、この処理時間はファイルサイズには影響を受けません。Firefoxの場合、起動に数秒を要してしまいます。セキュリティ対策のソフトが大抵の場合は必要が生じた際の動的なスキャンの結果をキャッシュしていて、再起動されるか定義ファイルが更新されるまでの間は再スキャンが行われないために、この問題がウォームスタート(訳注:ファイルがキャッシュ等に読み込まれた状態からの起動)の場合には起こらないという事には注意して下さい。
いくつかの他のブラウザは、起動時にDLLを2つだけ読み込んでいて、他は必要が生じた時(動画の再生、WebGLを使う場合など)に動的に読み込んでいます。これはFirefoxの場合よりもずっといい具合に動作しているように思われます。
検索してみた所、私はLinuxについてのこの件に対するバグをいくつか見つけましたが、Windowsについてのバグは見つかりませんでした。それらが1つの大きなDLL(xul.dll)とそれ以外の小さなDLL(それらは無条件に読み込まれる)となっているので、全てを1つのファイルにまとめるのは理にかなっていると思います。
Ben、あなたが注目した多数のDLLを提供している点についてはあなたの指摘は的を射ています。それについてのバグは https://bugzilla.mozilla.org/show_bug.cgi?id=561842 です。残念ながら、私達はこの作業をFirefox 4のリリースには間に合わせられませんので、後のリリース版で反映される事でしょう。
私はアンチウィルスソフトが起動時の処理に与える影響についても、より詳しい情報を得たいです。