Latest topics 近況報告
たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝1。Firefox Hacks Rebooted発売中。本書の1/3を使って、再起動不要なアドオンの作り方のテクニックや非同期処理の効率のいい書き方などを解説しています。既刊のFirefox 3 Hacksや拡張機能開発チュートリアルと併せてどうぞ。
オライリージャパン
宣伝2。日経Linux 2011年9月号から、Linuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。そちらもよろしく。
e10sオワタ - Nov 18, 2011
- Firefoxのマルチプロセス化、当面凍結 - 直近の性能向上を優先 | エンタープライズ | マイナビニュース
- Update on Multi-process Firefox (Electrolysis) Development | Lawrence Mandel
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、オライリーから出ました - Oct 27, 2011
既にご存じの方もいらっしゃるかとは思いますが、オライリーから「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% |
自分の担当箇所だけ細かく見てみると、ページ数と全体に対する割合はこんな感じです。
- Bootstrapped Extensions（再起動のいらないアドオン）の話：54ページ、11%
- 非同期処理の紹介：72ページ、15%
- そのうち、JSDeferredの紹介：43ページ、9%
- js-ctypes（6章）：27ページ、6%
調子に乗って脳汁ドバドバ出して書きまくる→ページ数が増える→値段上がる→損益分岐点も上がる という危険なコンボが発動してしまったためかお値段高めとなっておりますが、自分の担当箇所も他の方の担当箇所もひっくるめて、腰を据えて読むに値する情報ばかりなんじゃないかなーと思っております。Webで難なく読める文章の長さと、（紙でも電子でも）書籍の形になってた方が読みやすい文章の長さって、やっぱり違うと思いますしね。
本書のサポートサイトも公開されており、正誤表や本文中の各コードリストのダウンロード、本文の一部を切り出したサンプルPDFの無償公開などがあります。正誤表等はこれから更新されていくと思いますので、本書をお読みになられる際はこちらのサイトも併せてご参照いただければ幸いです。
以下は、思い出話です。
本書の企画がスタートしたのは、Firefox 4の正式版が出る前の2010年5月頃だったと思います（今メールボックスの一番古いメールの日付を見て確認した）。当時はまだ内部バージョンがFirefox 3.7とか言われていた頃で、Aero Glassが標準で入るのか？とか、そんな事を言ってた時期でした（という事も今Wikipediaを見て確認した）。
それからしばらく、どんな内容にするのがいいか？ どんな人に執筆を依頼しようか？（今著者の一覧に名前が載ってる方の中には、最初の時点で名前が挙がってた著者の側から「是非この人にも書いてもらいたい！」と引っ張り込んだ人もいるのです） という事を話し合っていて、執筆者が確定したのが8月。そこからぼちぼち書き始めて、なんやかやで1年経ってしまいました（普通はここまで難産にはならないみたいです）。その間にFirefoxのバージョン番号もどんどん上がっていって、もうすぐFirefox 8ですよ奥さん！ 時間が過ぎるのは本当に早いものですね。
最初の頃は、自分は「Firefox 3 Hacksで書いた内容をFriefox 4時点での情報に基づいてリライトするか？」程度の事を考えていました。でも、それじゃあ書いてる自分がつまらないし、それこそすぐに陳腐化してしまいます。それでうんうん唸りながら調べていくうちに、Firefox 4以降の話で新しい基盤の技術になりそうなトピックがいくつかあるという事が分かってきたので、それじゃあってんで、そこをターゲットにして書いていく事にしました。実は、自分の担当箇所は半年くらい前にほぼ完成してたんですよね。そこから本書の発売までの間は、（他の事に時間を使ってたからというのもありますが、）細かい記述のアップデート程度しかやってません。高速リリースになってからガンガン方針が変わったり実装が変わったりしてて、本書に書いた「テクニック」の中にも、既に「もうこんな回りくどい事しなくてもいいんだけどなぁ」な感じになってしまった話題がいくつかあるにはあるのですが（校正の詰めの詰めに入った段階でまたどどっと変更が入ってきて、どーしても間に合わなかったんです……）、全体としてはちゃんと今でも、そしてこれからも通用する話になってると思います。あの時の自分の目の付け所は、そんなには間違ってなかった、はず。
紆余曲折があった末にようやく世に出る事ができた本書ですが、アドオン開発者の方の手助けとなり、また、アドオン開発に手を出してみようと考えている方の手引きとなれば、幸いです。
他の著者の方々による本書の紹介のエントリ：
- Mozilla Japan ブログ - O'Reilly Japan から Firefox を使い倒す徹底活用本『Firefox Hacks Rebooted』が発売！
- Firefox Hacks Rebooted 発売します - すめるまん Broken Diary
- 詳細な目次も公開して下さってます。前述の表の数字はこれを元に計算しました。
- Firefox Hacks Rebooted - hogehoge @teramako
Firefoxでtarget="_blank"なリンクから新しいタブやウィンドウが開かれないようにしたい人向けの話 - Feb 04, 2011
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属性だったら無視しても問題ないでしょ？」→ 「どうしてもアドオン無しでやりたいならこういう方法もあるよ。」
という感じで、
- リンクの場合とJavaScriptの場合で新規ウィンドウ要求をどう扱うかの2つの設定項目は、初心者ユーザの事を優先して1つにまとめることにする。これは譲らない。
- そうすると、open_newwindow=1にするとWebサイトの動作を壊すなどのトラブルが起こりうる。なので、この値は設定UIには表示しない非推奨の隠し設定のままとする。
- リンクの場合とJavaScriptの場合で新規ウィンドウ要求をどう扱うかというのを細かく制御したい上級者ユーザは、アドオンを使うなり何なりして対処するように。
という結論に至った……みたいだ。
ということで、すっかり忘れてた＆調べ直してて改めて思い出したわけだけれども、browser.link.open_newwindowを1にすると、target属性があるリンクだけでなく、window.open()の読み込み先も現在のタブになってしまうために、親ウィンドウを参照するようなスクリプトが含まれてるページはまともに動かなくなる恐れがあるので、これはお薦めできません。トラブル覚悟でこの設定を使ってもいいけど、target属性があるリンクだけ同じタブで開くようにしたいという場合には、そういう機能を提供するアドオンを使うなり何なりしないといけないよーです。
まあ、いろんな場合に対して細かく挙動を振り分けたいという人は既に（当時の）Mozillaが考える所のメインターゲットではなかったのでした、そういう人は自分がマイノリティであることを自覚してDIYの精神で暮らすしかないですね、という話なのでした。
transitionendイベントが発火されないことがあるというバグが修正されそう - Jan 10, 2011
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の発生を予防できる）。パッチを書けない人でも書けないなりの協力はできるのです。単に「動かないよ」と言うだけの場合よりも、原因特定のための検証を開発者がやる手間が省けるから、効率がいいしバグも早く直る訳です。
- Mozillaの自動テストには、Mozillaのリポジトリに含まれているテストで実際に使われてるフレームワークが列挙されている。
- 今回のテストケースではその中の1つのMochitestを使った。
- Mochitestは基本的にはMozillaのビルド環境を整えた上で使う物だけど、MochiTest makerと最新のナイトリービルドを使えば、Mozillaのビルド無しにテストケースを書いて試すことができる。
- 実際にどんなテストがあるかは、MXRで「bug_」を名前に含むファイルを検索してみると色々な例を見れる。
- FirefoxのUIの上で操作した時に起こるバグの再現だったら、MozmillやUxUが使えるはず。
というわけで、バグ報告には確実に問題を再現できる手順（できれば自動テスト）を添えて下さいね、という話なのでした。
16日追記。パッチがチェックインされた後のナイトリービルドで、自分の環境では上記の問題が解消されていることを確認できた。よかった……これで安心してFirefox 4を迎えられるよ。
MNGMNGってお前はMNGキチか！って話 - Nov 25, 2010
背景。
- PNGの仕様には、アニメーション用の形式としてMNGというものも含まれてる。
- アルファチャネルを含んだアニメーション画像を作れる形式の1つ。
- 色々詰め込みすぎて仕様が膨大という欠点がある。
- Mozillaは過去（Mozilla Suite 1.7まで）にはMNGに一応対応してた。
- MozillaはFirefox 3で、MNGとは別のAPNGという形式に対応した。
- APNGはアニメーションできるPNG。
- MNGより仕様が単純。
- APNGの仕様はPNGの仕様の標準化グループに提出されたが、標準仕様には含まれない事になった。（なので今の所はあくまでMozillaの独自形式。）
- Mozillaは
APNGに対応する代わりにMNGに対応しなくなった（MNGデコーダがリリース版のバイナリには含まれなくなった）。- 「MNGなんて誰も使ってない」「そのくせデコーダがでかくてインストーラのサイズが無駄に大きくなってる」などがその理由だったようだ。
Web標準に対応しなくて自社独自の技術だけ使い続ける、というのはまあよくある事だから、ことさらMozillaだけをあげつらう事はないと思うんですよ。VMLには対応するけどSVGには対応しないというIE8までの方針であるとか、そういうのはありふれてる。
また、標準仕様はあるけどまだ実装されてない、っていうのもしょうがないと思うんですよ。仕様そのものが曖昧だとか、仕様が膨大すぎて対応できないとか、需要がそもそも無いとか。
釈然としないのは、
- 一度はMNGに対応していたのに、対応のためのコストが高いワリに需要がないからということで、対応しなくなった。 その後改めて需要が発生した（半透明のアニメーションを使いたくなった）時に、MNGサポートを復活させずに、別のもの（APNG）を新しく立てた。
- Mozillaはよく「Web標準を大事にしている」とアピールしている。Appleが「HTML5のデモです、これを見るにはSafariが必要です」って言ってる事に対してもMozillaは激しい非難をしていた。
これが僕には2枚舌に見えるってこと。
APNGに新たに対応して今後はそっちをメインで使っていくよ、というのはまあ別にいいんですよ。でも、今まで一応対応してたMNGをこれを機にばっさり切り捨てちゃう今まで一度は対応してたことがあったMNGを顧みることもなく別の物をっていうのはどうなん？ それじゃあ、なんかの動画形式で動画を埋め込んでて、その形式に対応してなかったらMNGにフォールバックして、みたいな事ができなくなっちゃうじゃんできないまんまじゃん？ フォールバック先にはやっぱり、仕様が標準化されてて安心して使える形式を選びたいじゃん？ そういう感じでMNGを使ってた使いたい人がいたかもしんないじゃん？ 僕はまだ使ってなかったけど、静止画の簡単なアニメーションを公開する事があったら是非そうしたかった。Web標準ってそうやって、地ならしっていうか下支えっていうかそういう所でも活きてくる物だと思ってたんですよ。
いやMozillaの言い分もわかるっちゃ分かるんですよ？
- 「中途半端に対応する方が、全く対応しないよりもよっぽど悪い」という考え方。
- 特に、バグがあるにも関わらず修正しないままずっと放置してて、間違った挙動や結果の方がデファクトスタンダードになっちゃう、というまずい事態が起こりうる。
- CSS2のrect()はそれでIEの実際の挙動の方に合わせて仕様がCSS2.1で「修正」されたんだっけ？
- 特に、バグがあるにも関わらず修正しないままずっと放置してて、間違った挙動や結果の方がデファクトスタンダードになっちゃう、というまずい事態が起こりうる。
- 人的リソースの問題。既にある機能を壊さないように維持し続けるコストの問題。
- Microsoftとかはサポート契約をしてお金を貰う代わりに長期に渡ってサポートし続けますよ、ということをやってる。そうしてコストを負担してもらえてるからこそ長期にサポートし続けられる。
- MNGに関して誰もそういうコストを負担してくれない以上は、MozillaはMNGをサポートし続けられない。
「MozillaはWeb標準を限定的にしか尊重しません。自分たちの組織を維持できなくなるレベルでコミットする事はありません。自己犠牲でWeb標準のために殉死するつもりはさらさら無いです。」というのは真っ当な判断だと思うんですよ。
でも、だったら、「お前はWeb標準を大事にしてない」って他者を非難する資格も無いんじゃないの？ 自分の事は棚に上げるの？ そういうみっともない事をしないでくれよ。Mozillaだけはそういう事をしてくれるなよ。
っていうモヤモヤがずっとある。
拡張機能の標準化の話について思うこと - Oct 20, 2010
- Operaがついに拡張を採用--「Firefoxのように重くはならない」 - CNET Japan
- Opera「ブラウザの拡張の仕様を標準化して、使い回せるようにしませんか？」 - CNET Japan
- Opera「ブラウザの拡張の仕様を標準化して、使い回せるようにしませんか？」 - WebStudio
かつて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本体には無いのに、拡張機能によって、タブを並べ替えられるようにできた。
- セッションを保存するという機能がMozilla本体には無いのに、拡張機能によって、前回終了時の状態を丸ごと復元したり、1回閉じたタブを開き直したりという事を実現できた。
- 検索ボックスでキー入力が始まったタイミングで自動的に表示されるポップアップから、別の検索エンジンで検索を実行する、なんてことすら実現できた。
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とかその後に出てくる物とかには移せないんじゃないかなー、と思ってる。些細な「イラッ」に目を瞑らずにストレートにそれを解消することができる、という居心地の良さに、僕はあまりにドップリと浸かりきってしまっているので。あまりに「自分を変えなくていい」事に慣れきってしまっているので。
Firefox 4: jar jar jar - Oct 06, 2010
この間悩まされたばかりのomnijarの話である、Taras’ Blog » Blog Archive » Firefox 4: jar jar jarの勝手翻訳です。分からない所が多かったので創作的意訳が多めですが気にしません。
ファイルを開く処理というものは、システムコールのための小さなオーバーヘッドや、ディスクからのデータの先読みによる大きなオーバーヘッドがある、比較的重たい処理です。データの物理的な配置の状態やディスクの種類によっては、この処理は今時の高速なCPUに対して、複数の異なるファイルそれぞれの全ての断片を先読みするためにディスク上をヘッドが激しく行き来する間、長々と無駄に暇をもてあまさせる事にもなり得ます。
最適化その1：裸のファイルをより少なくする
約2年前、私（訳注：元エントリの著者のTaras Glek）はディスク上にある裸のファイルを収集してjarファイルに詰め込む作業を始めました（例：bug 508421）。また、コードのクリーンアップやmmapへの移行などを通じて、私達はjarファイルの読み込み処理の効率も可能な限り改善しました。そして最終的には、通常の起動時にディスクから読み込まれていた、アプリケーションを構成するデータファイルの全てが、jarファイルの中に格納されるようになりました。しかし残念ながら、私達は4つのjarファイル（toolkit、chrome、そして2つのロケール用jarファイル）に構成ファイルをまとめる所までしか至れませんでした−−何ともマヌケな事ですけれども。またXPCOMの制限により、多数の裸のファイルがまだ、Firefoxのアップデートや拡張機能のインストールの度にディスクから読み込まれる状態となっていました。
最適化その2：全てを統べる1つのjarファイル
最近、Michael Wuがomnijarという
最適化その3：jarファイル内でのファイル配置の最適化
さて、今や全てのデータが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はこの問題を解決するための独自の読み込み用ライブラリを書いている所です。
最適化その4：さらなるomnijar
omnijarは十分に素晴らしいとはまだ言えないということで、Michael Wuはさらに先に進んで拡張機能をomnijar化しました（訳注：アドオンがXPIのままで認識されるようになった事を述べたエントリ）。ほとんどの拡張機能はXPIから裸のファイルに展開される必要が無くなる事でしょう。これは、拡張機能の作者が上記のような最適化されたjar形式を、Firefoxの起動を高速化するために利用できるという事を意味します。
その他のjarファイルの最適化
起動処理の高速化用のキャッシュをjarに切り替える事によって、私達は最初の起動処理をさらに最適化できるようになることでしょう。私が最適化されたjarファイルに加えた先読み用の情報を実際に利用する事によって、jarファイルのI/Oを半減できる可能性もあります。
元記事に寄せられたコメント
Benによるコメント（2010-09-23 05:32pm）
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つのファイルにまとめるのは理にかなっていると思います。
Taras Glekによるコメント（2010-09-24 09:06am）
Ben、あなたが注目した多数のDLLを提供している点についてはあなたの指摘は的を射ています。それについてのバグは https://bugzilla.mozilla.org/show_bug.cgi?id=561842 です。残念ながら、私達はこの作業をFirefox 4のリリースには間に合わせられませんので、後のリリース版で反映される事でしょう。
私はアンチウィルスソフトが起動時の処理に与える影響についても、より詳しい情報を得たいです。
アドオンマネージャの歴史 - Sep 22, 2010
History of the Add-ons Managerのオレオレ翻訳です。誤訳がありそうですが気にしません。
Firefox 4用の新しいアドオンマネージャのために行ってきた作業を通じて、これは興味深い話題だろうと思ったので、Firefoxのアドオンマネージャについてのこれまでの歴史と今後についてざっとまとめてみました。
Phoenix 0.2
Firefoxの最初期のバージョンにおいても、拡張機能は古いXPInstall形式のパッケージの仕組みを用いてサポートされていました。拡張機能の削除や無効化のための仕組みがFirefox自体に含まれていなかったため、これらの初期のアドオンマネージャは根本的な部分でいくつか問題がありました。また、あなたが初めてアドオンをインストールした後に目にするような拡張機能マネージャのウィンドウもありませんでした。拡張機能とテーマの一覧がFirefoxに初めて追加されたのはバージョン0.2の時で、その頃はこの製品はPhoenixと呼ばれていました。それは非常に基本的なUIで、設定ウィンドウの中に表示されていました。
Phoenix 0.2の「拡張機能」（2002年）Firebird 0.6
製品がFirebirdという新しい名前を得た後、拡張機能マネージャは設定ウィンドウ内の「テーマ」と「拡張機能」という個別のペインとして生まれ変わりました。
Firebird 0.6の「拡張機能」（2003年）Firefox 0.9
Firefox 0.9ですべてが変わりました。拡張機能マネージャは個別のウィンドウとなり、
Firefox 0.9の拡張機能マネージャ（2004年）テーマと拡張機能はそれぞれ別々のウィンドウで表示され、基本的な自動更新のための仕組みが搭載されました。これらはFirefox 1.0に向けたバックエンドのコードにおいて改良されることになっていました。この最初のバージョンは主にBen Goodgerによって書かれました。
Firefox 1.5
Firefox 1.5では拡張機能マネージャの表面的な部分について、ほんの少しだけ違いが見られます。このバージョンではFirefoxの他の部分の外観のスタイル付けに合わせるためにごくわずかな変更が行われました。
Firefox 1.5のスクリーンショット（2005年）この舞台裏で、Darin Fisherは大きな変更を行いました。彼は拡張機能マネージャに対して、Windowsのレジストリを含む、システム上の異なる場所から拡張機能を読み込むことを可能にしたのです。彼はまた、拡張機能をプロファイルフォルダ内に抽出することを可能にし、次にFirefoxが起動された時に自動的にそれらを認識できるようにもしました。この時、リリースに向けて拡張機能マネージャを安定させるために、Rob Strongがモジュールオーナーの権限を引き継ぎました。また、このバージョンには拡張機能マネージャに対する私（※訳註：原文の著者のDave Townsend氏）の最初のパッチも含まれています――bug 307925においての物で、ごく小さな物ですが。
Firefox 2.0
Firefox 2.0では最終的に、分割されていた拡張機能とテーマのウィンドウが一つのアドオンマネージャに統合されました。
Firefox 2.0のアドオンマネージャ（2006年）水面下では、ユーザにとって危険と判断された拡張機能をMozillaの手で外部から無効化する事を可能にするためのブロックリスト機能の最初のバージョンを含む、さらに多くの変更が行われていました。この機能が作られて以来、私たちはこの機能を本当にごく希にしか使っていませんが、セキュリティ上の弱点やクラッシュを防ぐ際の助けとなってきました。
Firefox 3.0
Firefox 3において、私たちはプラグインをアドオンマネージャの中に含めるようにし、また初めての利用において皆さんがアドオンマネージャを使ってaddons.mozilla.orgからアドオンを直接ダウンロードしてインストールできるようにしました。これは私（※訳註：原文の著者のDave Townsend氏）がFirefoxにおいて作業した最初の大きな機能で、この機能がどれだけ使われているかをアドオンチームから聞く度に、私はいつも非常に嬉しい気持ちになります。
Firefox 3.0のアドオンマネージャ（2008年）内部的には、ブロックリスト機能はプラグインをブロックできるように拡張され、Windows以外のプラットフォームにおいてもシステム上の他のアプリケーションとの連携に対応するためにインストール対象となるファイルの置き場所が新しく追加されました（※訳註：bug 311008）。
Firefox 3.5と3.6
Firefox 3.5と3.6においては視覚的な変更点は全くありませんでしたが、Firefox 3.5ではブロックリスト機能がいくつかの異なる重要度のレベルに対応できるように再度改良され、Firefox 3.6ではシステム上にあるアップデートが必要なプラグインについてユーザに警告を行う機能への対応に加えて、Firefoxのメインウィンドウの単調な背景を簡単に切り替えられるようにする、産まれたばかりのペルソナがアドオンマネージャに搭載されました。
Firefox 4.0 beta
Firefox 4では、再起動が不要な拡張機能への対応の追加や、ユーザの操作をより妨げない自動的な更新のための仕組み、そして新しいアドオンに出会うためのより便利な方法などを含む、アドオンマネージャの全面的な再設計が見られます。
Firefox 4 betaのアドオンマネージャ（2010年初頭）
裏側においては、新しいアドオンマネージャは新しい種類のアドオンを、これまでよりもさらに簡単に管理できるようになっています。
Firefox 4.0
ユーザ・エクスペリエンスチームは、Firefox 4のリリース版でアドオンマネージャがどのように見えるようになるかの最終的なデザインを作成するために、一生懸命働いています。あくまで仮の物ですが、これは彼らが行おうとしていることのスケッチです：
Firefox 4最終版用に検討中のデザイン（2010年末頃？）
将来的に、私たちはさらに多くの種類のアドオンをこのマネージャの中に持ち込むことを計画しています。現在はそれ用の独自のウィンドウで管理されている検索プラグインなどのような物は、ここにうまく収まるでしょう。また、私たちは皆さんが拡張機能をより単純な形でカスタマイズするようにしたいとも考えています。可能性は低いですが、私たちは拡張機能の開発者達に対して、独自の設定ウィンドウを作る事を許容するのをやめて、新しいウィンドウを開くことを必要とせずに、単純な設定をアドオンマネージャの中で直接変更できるようにする機能を加える事を検討しています。私たちは、皆さんがインストール済みのプラグイン――それは時にセキュリティ上の問題や、安定性を損なう問題の元になります――を自動的に更新する方法を実現できたらと考えていますし、テーマの選択について、どんなテーマが利用可能かを見たり、それらを切り替えたりするのを、より簡単に行えるよう大幅な改良を行いたいとも考えています。
これらのことのうちのいくつかはFirefox 4.0までの時間で実際に行われるかもしれませんが、最終的なリリースの前に新しい物を取り入れるには、時間は残り少ないです。
タブの追加・削除のアニメーション - Aug 08, 2010
Firefoxで、タブを閉じる時にいきなりタブが消えるんじゃなくちょっとずつ消えるようなアニメーションが実装されたようだ。ツリー型タブにアニメーション効果を加えた時にも書いたけど、状態が不連続に変化するよりも連続的に変化した方が分かりやすいことは間違いないので、この改良は歓迎すべき事だと思う。
使い勝手的な面とか見た目的な面とかでは多分他の人が言及していると思うので、僕は実装とかAPIとかの面で感心した点に言及してみる。
このパッチが入るちょっと前に「新しいタブを開く時にアニメーション効果を適用する」という処理も入ったんだけど、この2つには違う所が1点ある。それは、既定の状態がアニメーション有りか無しかという点だ。
gBrowser.addTab(uri)で、アニメーション有りでタブが開かれる。gBrowser.addTab(uri, { skipAnimation : true })で、アニメーション無しでタブが開かれる。gBrowser.removeTab(tab)で、アニメーション無しでタブが閉じられる。gBrowser.removeTab(tab, { animate : true })で、アニメーション有りでタブが閉じられる。
今回のremoveTab()の既定の挙動とフラグ指定の仕様は大いに評価したい。何故かというと、これは互換性を最大限保つために必要なことだからだ。
タブを閉じる時にアニメーション効果を適用させるということは、タブに「閉じるという操作は行われたが、まだ実際にはDOMツリー状に存在している」という状態が加わったということだ。そのため、gBrowser.mTabContainer.childNodesで取得したタブの一覧の中に、本来であれば処理対象にしては行けないタブが含まれてしまうようになる。
これは大いに混乱を招く。アドオンの多くはタブを閉じる際のアニメーション効果のことなど知らないから、タブが閉じられたらすぐにDOMツリーからも消えることを期待している。そういう前提で書かれたコードが、片っ端から動かなくなってしまう恐れがある。
今回のパッチでは、この混乱を最小限にするための配慮が行われている。このような状態が発生する場面を「タブのクローズボックスがクリックされた時」と「Ctrl-Wなどのキーボードショートカットで現在のタブが閉じられようとした時」だけに限定することで、それ以外の場合は明示的に指示されない限りはアニメーションしないようにしてある。アドオンが要であるFirefoxとしては、APIの変更でアドオンが作りにくくなる・人気のアドオンが動作しなくなることのデメリットの方が、美しい設計のAPIにすることのメリットを上回ると考えられるから、この判断は合理的と言っていい。
今後の課題は、互換性を重視したことでAPIが分かりにくくなってしまった点をどうするか、ということではないかと個人的には思っている。特に、addTab()とremoveTab()という対になったAPIにおいて、似たような事をやるのにそれぞれやり方が違うというのは、あまり誉められる事ではないから。
ただ、今はとにかく、Mozillaが互換性を重視する決定をしてくれたことをありがたく思っている。
Firefox 4のTabs on Topを受け入れられないのは頭が硬直化している証拠 - Jun 28, 2010
タイトルは半分は釣り。
Firefox 4のUIのモックアップでそれが目標として示されて以降、「タブがツールバーの上に表示されるようになる」という変更に対しては色んな人が反対の意を示しているようだ。以下もそのひとつ。
反対意見があまりに多いためか、Mozillaもわざわざ動画まで用意して Tabs on Topの正当性を必死で主張している。
この件に関して僕は一貫して、タブをツールバーの上に移動するという決定には賛同している。というか、できる事ならもっと前の時点でそうするべきだったと思っている。今の（Firefox 3.6の）UIのデザインを「この方が優れている」という論調で肯定する意見は、ちゃんちゃらおかしいとしか言いようがない。
何故そう言い切れるかというと、今のUIのデザイン（タブがツールバーの下にある）は、言っちゃあ悪いが、実装者の都合に基づくやっつけ仕事の積み重ねの末にある結果でしかないからだ。Firefoxの前身であるPhoenixが出てくるより前、初めてMozilla本体でタブブラウズ機能を実装し始めた頃から見ていたら、それはもうはっきり分かることだ。
そもそもなんでタブがツールバーの下にあったのかと言えば、それまでのタブが無いUI（Netscape Navigator由来）の中にタブを組み込みつつ、他の部分のコードとの互換性を最大限保つために、変更箇所を最小限にとどめる形で実装が行われたからだ。最初のタブブラウズ機能は、それまで「ブラウズ領域」を確保するために用意されていたbrowser要素（iframe要素の高機能版と思って貰えばいい）と入れ換える形でtabbrowser要素という物を置き、タブに関する変更は全部そのtabbrowser要素の中で完結させるという方向性で実装された。それ以後Firefox 3.6に至るまで、根本的な設計はずっと当時の物を引きずってきた。
ここで重要なのは、タブがコンテンツ領域の真上に置かれたこと、ツールバーの下に置かれたことに、ヒューマンインターフェースのデザインの観点からの理由は全く無かったという点だ。理由があってそうしたのではなく、単に「そうするのが実装上簡単だったから」でしかないのだ。
さて、「使いやすい」UIの設計にはいくつかのセオリーがある。
- 持って欲しい所は持てそうなように、押して欲しい物は押せそうな形に、見た目を作ること。
- 見た目が現在の状態を示すようにすること。
- 行う操作と、その結果との関係性を分かりやすくすること。
- 他の物に合わせること。
まず第一に、望ましい操作、やって欲しい操作にユーザを誘導するような見た目にするということ。例えば、棒のように突き出た部分があれば人はそれを掴んでみようとするだろう。ぽちっと出っ張った部分があれば人はそれを押してみようとするだろう。見た目は人の行動を誘発する。WindowsでもMac OS Xでもなんでも、ボタンが出っ張った見た目をしているのはそのためだ。
第二に、見た目から状態がすぐに分かるようにするということ。ボタンが「押し込まれた」ような見た目をしていれば、それはもうこれ以上押せないと分かる。オブジェクトの影が他の物の上に落ちていれば、そのオブジェクトが他の物よりも上（手前）にあると分かる。Windows VistaでもMac OS Xでもウィンドウに影が落ちているのはそのためだし、Aero Glassで下のウィンドウが透けて見えるのもそのためだ。
第三に、それを操作したら何が起こるかがはっきり分かるようにするということ。包丁を見たら、取っ手を持って振れば刃も一緒に動く事が分かる。ハサミを見たら、取っ手を握れば刃も動く事が分かる。そういう風に構造が見て取れるものでないなら、何らかの方法で「これを触ったらここがこうなりますよ」って事を分かりやすく示さないと行けない。飛行機のコクピットで着陸脚を操作するためのハンドルがまさに着陸脚そのものの形をしているのは、そのためだ。
最後に、既に似たものがあるのならそれに合わせるということ。今まで使っていたものに似ていればそれだけすぐに使えるし、今まで使っていたものと違っていたらそれだけで操作ミスが増える。自動車のブレーキとアクセルの並び順が、ある車種ではブレーキが左・アクセルが右で、別の車種ではブレーキが右・アクセルが左、なんて事になっていたら、これで事故が起きない方がおかしい。
翻って、今（Firefox 3.6）のタブはどうだろう。
タブ単体の見た目は、悪くない。フォアグラウンドのタブとバックグラウンドのタブはそれなりに見分けやすいし、選択されているタブが他のタブより手前にあるように見えるのも悪くない。押せそうな形をしているし、押せばタブが切り替わる。つまめそうな形をしているし、つまめば並べ替えもできる。
でも、「タブを操作したら何が起こるのか」は致命的に分かりにくい。
- タブをクリックしたら、タブの上にあるナビゲーションバーの内容と、タブの下にあるコンテンツ領域の内容が変わる。
- ウィンドウの真ん中あたりにあるタブを閉じる操作をしたら、タブだけでなくウィンドウまで閉じられる。（これなんかは、あまりに酷すぎて僕自身ボロクソに貶しもした。）
- そもそも、タブが開かれたという事に気づきすらしない人もいる。リンクをクリックしたらボタンっぽい物が1個増えた、でもそれが何なのか分からないし、どうして増えたのかも分からない。
タブをツールバーの上に置くのは、「タブを操作したら何が起こるのか」を視覚的にはっきり示すための一番ストレートで確実な方法なんだ。
とはいえ、今Tabs on Topが非難を浴びているのもまた、上に書いたセオリーの通りではある。「他の物、今までの物に合わせる」ということ。比較の対象は「今のFirefox」に他ならない。
「他の物、今までの物に合わせる」、これは他のすべてを覆しかねないほど重要な事だ。なんだかんだ言って、人は自分の行動を変えようとしないし、今の物と違う物には拒絶反応を示す（上に挙げたそれ以外のセオリーは言わば、「今までの物がどうして使いやすかったのか」を分析する事で、「合わせる」先の既存の物が無い時に新しい物をどう設計するかの指針を示したものと言える）。今までの物に合わせないで別の物を提示するという事には、今までの支持を失うリスクがある。新しい物に絶対の自信がなければ、「今の物と違う」という理由でついて来れなくなる人よりも、新しい物の「分かりやすさ」によって引き付ける事のできる人の数の方が多いと信じていなければ、新しい物は取り入れられない。
要するにMozillaは、今までの支持者を失うリスクよりも、新しいUIで取り込める層の方が多いと見込んだという事だ。あるいは、失った支持者すら、新しいUIの分かりやすさによってもう一度取り込め直せるだろうと見込んでいるのだろう。それだけMozillaは新しいUIに自信を持っているのだろう。
ただ、どうしても受け入れられないという人のためにTabs on Topを無効にするオプションも用意しているあたりが、Mozillaらしいと言えばらしい譲歩ではある。例えばジョブズあたりはこの辺もっと割り切っていて、新しい物を出したら古い物はバッサリ捨てるという風に容赦がない（iMacでのレガシーインターフェース一掃やiPadの有線LAN非対応などはそのいい例だろう）。
まとめよう。
不幸な事にMozillaは、それまであまり知られていなかった「タブブラウズ」という概念を取り入れるにあたって、UI設計のセオリーをまるで無視した実装上の都合からタブブラウズのUIを作ってしまった。
しかし今は違う。メジャーなブラウザはいずれもタブブラウズ機能をサポートし、タブの位置についても、Tabs on Topを採用した例はOperaに続いてGoogle Chromeがある。Firefoxを除けば、タブをツールバーの下に置いているのはIEとSafariだけだ。そしてそのSafariは、タブの連結方向を下ではなく上に向ける事で、少なくともツールバーはタブに従属するものという事を視覚的に示している。採用している実装の数だけを言えば、ツールバーをタブに従属させるデザインの方が多数派になったとすら言える。昔の実装の負の遺産を断ち切るにはそろそろいい頃合いだ。
Tabs on Topに対する非難ははっきり言って、「今までの物と違う」という事それ自体に対する拒否反応でしかない。だから、それを正当化するために「今の配置の方が合理的なんだ」なんておかしな事を言う必要はない。そんな屁理屈を用意しなくても、あなたがTabs on Topを受け入れられない理由は「今までの物と違うから」それだけで十分だ。それは恥ずかしい事じゃあない。「新しい物を作る時はなるべく今ある物に合わせろ」というのが鉄則になるくらいには、人類みな頭が固いんだ。
そして、今までの物を覚えるのに苦労した分だけ「またあんな苦労をして新しく覚え直さなきゃならないのかよ！」と言いたくもなるだろうが、それは杞憂だ。Tabs on Topな新しいUIは、今までの物を覚えるのに要した時間よりもっと短い時間で慣れる事ができる。何故なら、今までタブを使った事がなくてもそのはたらきが見た目で分かる、そういう所を目指したデザインなんだから。
