Latest topics 近況報告

ツリー型タブでタブのツリー構造を高速に復元できるようにしたりPDFでも「自動でタブバーを隠す」できるようにしたりした - Dec 14, 2011

Tree Style Tab 0.13.2011121401で、長年の課題だった点に対する改善を入れてみた。現実逃避です。

まず1点、ツリーの復元にすごく時間がかかるという問題。。

今まではSSTabRestoringイベントのタイミングでツリー構造を復元してたんだけど、これだとタブがちょっとずつしか復元されないせいでツリーもちょっとずつしか復元されない→ツリー全体が復元されるまで場合によってはものすごく時間がかかる、という問題があった。でもSSTabRestoringイベントが発行される前の時点ではnsISessionStoreのsetTabValue()で保存した情報を取り出せないからどうしようもなくて、ずっと放置してた。

これが最近のバージョンのFirefoxではSSTabRestoringより前でもセッションに保存された情報を取り出せるようになってたので、じゃあってんで、真っ先にツリー構造だけ復元するようにしたという次第。

前のエントリではnsIObserverでメッセージを拾うとか何とか書いたけど、結局その方法はやめた。最終的にどうやったのか、という事を簡単に書いておく。

おさらいとして、Firefoxが備えているセッション復元機能は以下のような流れで処理を行っている。

1. SSWindowStateBusyイベントが発行される。
2. 必要な数のタブを開く。タブを使い回す時は、今読み込んでいるタブの内容を破棄する。
3. セッションの情報に基づいてタブを初期化する（表示・非表示の切り替え、タイトルの設定など）。この時SSTabRestoringイベントが発行される。
4. セッションの情報に基づいて履歴を復元する。この時SSTabRestoredイベントが発行される。

問題は、1と2の間に割り込んで、2で使い回される事になるタブのツリー構造を一旦リセットしないといけないけど、そのためのAPIが無い（どのタブが使い回される事になるのか、を知る方法が全く無い）っていう事。

• __SS_tabStillLoadingとか__SS_restoreStateとかを見たら分かるんじゃないか？と思ったけど、これを使っても、「Bar Tab相当の機能」によって待機状態のままになってるタブと、これからセッションが復元されようとしている状態のタブとを見分けられない。
• プロパティアクセスやDOMノードへの属性値の設定を監視するのはコストが大きそうだし、他のアドオンやFirefoxの機能を壊してしまいそう。
• タブを使い回す直前にnsISHistoryのPurgeHistory()というメソッドが呼ばれていて、nsISHistoryにはnsISHistoryListenerインターフェースを備えたリスナを登録できるようだったので、これを使えばいけるか！？と思ったけど、nsISHistoryには1個しかリスナを登録できなくてアドオンでリスナを追加するとFirefox自身が追加したリスナが失われてしまって、全体的に動作がぶっ壊れてしまった。
• nsSessionStoreはJavaScriptコードモジュールではなくXPCOMコンポーネントなので、プロトタイプやシングルトンとして動作してるインスタンスに対してフックを仕掛ける事もできない。

とかなんとかああでもないこうでもないといじり回していて、もう最後の手段という事で、<browser/>のstop()を置き換えてフラグを立てたり下ろしたりするようにした。nsSessionStoreは1と2の間で、使い回す予定のタブをプライベートメソッドのrestoreHistoryPrecursor()に渡してそれらの内容を初期化するという事をやってて、その中で必ずstop()を呼んでいたので、stop()が呼ばれた時にJavaScriptのスタックを辿って、restoreHistoryPrecursor()から呼ばれていたら「このタブはこれから使い回されようとしている」というフラグを立てるようにした。restoreHistoryPrecursor()は他の場所からは絶対に呼ばれないから、これが一番確実だと思う。

そうすると、

1. SSWindowStateBusyイベントを拾って、「これからツリーが復元されようとしている」ことを検知して、「ツリーが復元されようとしている」フラグを立てる。
2. restoreHistoryPrecursor()のタイミングで、「これからセッション情報が復元されようとしているタブ」にフラグが立つ。
3. 復元されるタブの1個目に対してSSTabRestoringイベントが発行される。この時、「ツリーが復元されようとしている」フラグが立っていたら、2でフラグが立てられたタブだけを収集してきてツリー構造を復元する。
4. 2つ目以降のタブのSSTabRestoringイベントが発行される。以下略。

という具合にして、個々のタブのセッションの復元完了を待たずに一気にツリー構造を復元できるようになるわけです。

この改善は、Firefoxのセッション復元APIを使ってるSession Managerとの併用でもちゃんと活かされる。Tab Mix Plusみたいに独自のオレオレセッション復元機能を持っててそれを使ってる環境は……知らない。多分動かないだろうけど対応する気力無い（そもそも、僕自身Session Managerは使っててもTMPは使ってない）。

次、2点目。タブで開いてる内容がPDFだったりFlashだったりすると「タブバーを自動で隠す」が機能しないという問題。

ポインタの位置に応じて自動的にタブバーを表示したり隠したりという事をやるためのベタなやりかたは、Firefoxのウィンドウ（XULドキュメント）でキャプチャリングフェーズでmousemoveイベントを監視するという方法だ。ポインタがタブバーの近くに来たらタブバーを表示して、コンテンツ領域の上に載ったら（タブバーから離れたら）タブバーを隠す、という感じ。AutoHideというアドオンはそうしてたし、ツリー型タブもそうしてる。

ところが、何度か中野さんが解説されてた気がするけど、Firefoxはプラグイン（FlashとかPDFとか）の描画領域の上で発生したクリックやら何やらのイベントは全部プラグインが握りつぶすようになってる。そのため、普通にmousemoveイベントを監視してても、プラグインの領域にポインタが載ってる間は何もイベントが発生しない。ポインタがタブバーから離れた事はmouseout等で検知できても、コンテンツ領域に載ったという事を検知する事ができない。

（ちなみに、ツリー型タブではタブバーの「近く」にポインタがあるときはタブバーを隠さないで、ちょっと離れたら初めてタブバーを隠す、という風にしている。そうしないと、タブバーの幅を変えるためにスプリッタをドラッグしようとしても、ちょっとポインタがぶれただけですぐタブバーが隠れてしまってストレスが溜まってしょうがない。なので、mousemoveでポインタの座標を監視するという方法に頼らざるを得ないのです。）

同じ理由で、マウスジェスチャ系のアドオンもプラグインがあるとジェスチャがまともに動かないという事が結構あるみたい。そこをどうにかしようとすると、CとかC++とかでコンポーネントを作ってもっとプラットフォーム寄りの所でポインタの位置を拾うしかなくて、「プラグインの上でもジェスチャできる」が売りのMonkey Gesturesは実際そのようにしてたと思う。

ネイティブなコンポーネントを書くというのは嫌っていうかそんな手間かけたくなかったので代わりにどうやったかっていうと、すごく単純な話で、background: rgba(0,0,0,0.01) !important; -moz-appearance: none !important;にした<panel/>をコンテンツ領域の上に重ねて開くようにした。たったそれだけ。そうするとXULの要素の上だから普通にmousemoveイベントが発生して、ポインタの正確な位置を取れるようになった。

透明なポップアップを表示する時には、セオリーというか注意点がいくつかある。

• background: transparent !important;で完全な透明にしてはだめ。完全に透明な<panel/>は何のイベントも拾ってくれない。なので、rgba(0,0,0,0.01)（ものすごく薄い半透明の黒）のように、何かとにかく色を付けておく必要がある。
• Linuxでは半透明のpanelは表示できない（Geckoが対応してなくて、ピクセルごとに完全透明か完全不透明かのどっちかしかできない）。なので、background: transparent !important;で完全透明にしつつborderでちょっとだけ線を表示して、<panel/>の中に不透明な部分を作ってやる。
  • ただ、それだとcompiz等ではpanelに影ができてしまってかっこわるい。不透明な部分が矩形になってると影ができて、矩形以外の形だと影ができないっぽい（ロケーションバーのfaviconの所に出るドアハンガーUIに影が表示されないのもこれが理由）ので、<panel/>の左右にだけ枠線を付けるという風にして、領域が矩形にならないようにする。

透明な<panel/>を使う方法にはいくつか弊害があって、今まではそれを気にして採用を避けてた。が、今回のアップデートではそれぞれ「できる所までは頑張ろう、どうしても無理な所はもう知らん」というスタンスで割り切ることにした。

• ユーザがコンテンツ領域の中をクリックしたつもりで<panel/>がクリックされてしまうと、「クリックしたのに何も起こらない」という状況が発生してしまう。
  • →タブの内容がプラグインで表示されてるかどうかを見て、必要な時だけ透明な<panel/>を使うようにした。タブバーが隠れて<panel/>が閉じられた後でなら普通にクリックできるので、タブバーが隠れる前にコンテンツ領域をクリックするようなせっかちな人の事はもう諦める事にした。
• 透明な<panel/>以外の部分(ツールバーボタンなど）をクリックすると、環境によっては、透明な<panel/>が閉じられるだけで終わってしまう。
  • →popupBoxObject.setConsumeRollupEvent(Ci.nsIPopupBoxObject.ROLLUP_NO_CONSUME)である程度は抑制できるっぽい（Ubuntu 10.04LTSのcompizだと、Firefoxのウィンドウの中に対してはclick-throughが通用するようになったが、他のアプリケーションのウィンドウをいきなりクリックした時は相変わらずだった）。どうしても駄目な時については、もう、諦める。

なんで方針を変えた（安全に完璧に提供できない弊害の多い方法は使いたくない→弊害があっても使う）かというと、「同じ要望がもう数えるのも嫌になるくらいしょっちゅう来ててウンザリしたから」っていうのが最大の理由だ。

いや、つまり「PDFとか表示してるとタブバーが隠れてくれない」問題は、割と誰でもぶち当たってしまう問題なわけですよ。それに対して、実際に調べたわけではないけど、多分上に挙げたような「弊害」が実際に致命的な問題になるような人は多分そんなに多くないだろうと思うわけですよ。どっちの人を大事にしたらいいかっていう事で天秤にかけて、前者を救う事にした。という話なのです。

そういう意味では、TMPの独自のセッション復元機能を使ってる人を見捨てるってどうなんっていう言い方もあるだろうけど、あんなもん（TMP独自のセッション復元機能）ぶっちゃけ捨てていいですよ。Firefox本体のセッション復元機能に勝ってる部分、ありますか？　ないですよね？　いやよく調べないまま書いてるんだけどさ。

nsISessionStoreのsetTabValue()/getTabValue()がSSTabRestoringイベントの前でも使えるようになっている件 - Dec 07, 2011

で、それを活用できるのはいつのタイミングなのよって話。

ツリー型タブはツリー構造の復元にSSTabRestoringイベントを使っているのだけれども、Firefoxのセッション復元機能はタブを1個ずつ復元していくために、100個とか大量にタブを開いているとツリー全体が復元されるまでにめちゃめちゃ時間がかかってしまうという問題がある。

これを何とかしたくて、setWindowValue()/getWindowValue()を使ってタブではなくウィンドウそのものの方にツリーの構造の情報を持たせるとかそういう事を実験してみてたんだけど、いまいち期待したような結果を得られなくて長らく放置してた。

が、最近また同じ要望が上がってて、「だから無理だって言ってんじゃん……」と思いながらその時作った実験的なコードをもう一度いじってみたら、予想に反して結構期待に近い感じで動くようになっていた。

そもそも何故過去に実験した時に期待したような結果を得られなかったかというと、SSTabRestoringイベントが発行される前のタブに対してsetTabValue()/getTabValue()をやった時の挙動が怪しかったからだった。少なくともFirefox 3.6では、SSTabRestoringイベントが発行される準備が整った時点まで待たないと、前回保存したはずの値をgetTabValue()で取れないという制限があった。それでは結局、普通にSSTabRestoringを待つしかないという事になってしまう。

それに対して今のFirefoxでは、タブが選択されるまでは内容をロードしないという機能が取り込まれていて（主にメモリの節約のためと思われる）、「セッションは完全には復元されていないが、setTabValue()/getTabValue()で情報を保存したり読み取ったりされる」という状態を考慮する必要がある。そのためいつの頃からか実装が変わって、SSTabRestoringを待たなくてもgetTabValue()で前回保存した情報を読めるようになってた。（という事に、今回初めて気がついた。）

SSTabRestoringを待たなくてもよくなった、という事は分かったんだけど、じゃあ問題はいつのタイミングでなら安心してgetTabValue()できるのかっていう事。DOMContentLoadedなのか、loadなのか、それともそこからさらにsetTimeout()で遅らせた方がいいのか？　できれば早いタイミングでやりたいけど、あんまり早くやり過ぎると他の処理を壊してしまいそうで怖い。

何かヒントはないかとnsSessionStore.jsを調べたところ、sessionstore-windows-restoredまたはsessionstore-browser-state-restoredというtopicのObserver NotificationをnsIObserverとして受け取ればよさそうだということが分かった。これらはsetWindowState()された後にそのイベントループの最後で発行されるObserver Notificationで、どっちが発行されるかは場合によって変わるんだけれども、どちらも全く同じタイミングで発行されている（三項演算子でtopicだけ切り替えてるようだった）。なのでこのタイミングでgetTabValue()した情報に基づいてツリー構造を復元するようにしてみた所、無事成功してくれた。

ということで、SSTabRestoringでは物足りないという人はこれらのObserver Notificationを使うといいと思います。

FirefoxのmozRequestAnimationFrame()の仕様が変わってた - Dec 02, 2011

2011年11月30日付けのNightly 11.0a1でツリー型タブが動かないっていう報告を受けたので調べてみたら、なんかJavaScriptベースでアニメーション効果を実装する時に使えるFirefox 4から（だったっけ？）の新しい機能に基づいたアニメーション管理のための仕組みが期待した通りに動かなくなってて、あれこれ試してるうちにどうもmozRequestAnimationFrame()の使い方のうちDOMイベントベースでやる方のが動かなくなっててコールバック関数を使う方法でならうごくっぽいという事が分かったので、ツリー型タブ0.12.2011120101からはそのように変更した。

えむけいさんが教えて下さった所によると、これはBug 704171 – Remove the no-argument form of requestAnimationFrameでの変更による物で、要するに「DOMイベントベースの方法は正式な仕様になりそうにないし誰も使ってないし、もう廃止してよくね？」ってことで、Geckoでしか使えなかったDOMイベントベースの方法は廃止されて、WebKit等でも利用できるのと同じ形式のAPIに統一されたんだそうだ。まさにその当日にMDNのドキュメントを調べてて、その廃止された方の使い方が解説されていて、MDNにも書いてある使い方なのにおっかしーなーと首をひねってたんだけど、単にドキュメントの更新が間に合っていなかっただけだった。

現実的には妥当な決定だと思うけど、なんか釈然としない。例外のメッセージで「仕様が変わった、古い使い方はもう使えない」とかそういう情報を出してくれれば、もうちょっとすんなり原因に気がつけただろうに……

Firefox Hacks Rebooted 4章正誤情報速報 - Nov 20, 2011

Firefox Hacks Rebootedの正誤表を早いとこ作らないといけないという事は認識しているのですが、他の事に忙殺されていて手を着けられていません。なので、自分の担当章で現在把握しているミス、出版後に状況が変化した点などについて書いておきます。（ここに書いた内用は、いずれ本書のサポートサイトにもまとめる予定です。このエントリは「速報版」ということで。速報と言うには遅すぎますが……）

Bootstrapped Extensionsでのchrome.manifestについて（Hack#33 、217ページ）

本書での解説のうち、chrome.manifestの読み込みの方法の記述が事実と異なっています。

Components.manager.addBootstrappedManifestLocation()およびComponents.manager.removeBootstrappedManifestLocation()には、 chrome.manifestのファイルの位置ではなく、XPIファイルもしくはchrome.manifestがあるフォルダの位置を渡します。別のファイル名・別の位置のマニフェストファイルを読み込ませたい場合は、chrome.manifestの中からmanifestディレクティブで間接的に読み込ませる必要があります。

なお、Firefox 8および9ではBootstrapped Extensionsに含めたchrome.manifestは自動的には読み込まれませんが、Firefox 10からは自動的に読み込まれるようになります（Bug 675371）。

e10s（プロセス分離）について（Hack#34～38、219ページ～249ページ）

各地で既報の通り、デスクトップ版Firefoxのe10s有効化は当面行われない事になりました。これらの節で解説しているMessage Managerの仕組み自体はまだ残されるものと思われますが、個人的な予想として僕はMessage Managerの仕組み自体も将来的に削除されてしまう可能性があるとも考えています。ですので、何らかの事情でどうしても使わないといけないという事でない限りは、Message Managerの仕組みは使用しない事を、僕個人としてはお勧めします。

かなりのページ数を割いたにも関わらずこういう事になってしまって、本当に残念です。既に本書の内容を参考にe10s対応のための準備を始めていた方もいらっしゃる模様で、Firefox 3 Hacksの時のFUEL解説と同じように、結果的に皆さんを振り回してしまう事になってしまい誠に申し訳ありません。

プログレスリスナの実装について（Hack#33 、237ページ～238ページ）

サンプルコード中でnsIWeakReferenceという記述がありますが、これはnsISupportsWeakReferenceの誤りです。

ワーカースクリプトでのdata: URIの利用について（Hack #42、271ページ）

data: URIは利用できないと書いていますが、Firefox 10からはdata: URIも利用できるようになります（Bug 699857）。

ワーカースクリプト内でのXPConnectの利用について（Hack #42、276ページ）

本節ではChromeWorkerの名前空間で、XPConnectへのアクセスのためにXPCOMというオブジェクトを利用できると書いていますが、Firefox 8正式版ではこの機能は廃止されました（Bug 649537）。ワーカーの名前空間からは、XPConnectは一切利用できません。

ただ、本節で述べている通り、元々ワーカーの名前空間からXPConnect経由で利用できる機能はほとんど無かったという事と、js-ctypesは引き続き利用できる（Nightlyで実際に確認しましたので、これは間違いないです）という事から、実質的にはほとんど影響の無い変更だったと言えます。

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領域のスクリプトから触り放題な設計は、いずれにせよそのうちオワコンになっちゃうのでしょう。

オチはありません。

続きを表示する ...

再起動のいらないアドオンのコンテストが11月8日頃〆切で行われているそうですね - Nov 01, 2011

Firefoxアドオンコンテストの要項を意訳してみた。 - おんがえしの日記で報じられていますが、「再起動のいらないアドオン」というテーマでアドオンのコンテストが開かれているそうです。

再起動のいらないアドオンというとAdd-on SDKを使って開発すればそういう風になる訳ですが、何度か勉強会等で話している通り、再起動のいらないアドオンを作るだけならSDKなしでも作る事は可能です。そういう物も応募できるのか？　という質問がやはり告知のページにも寄せられていて、回答としては、「SDKなしでもいいよ」と書いてありました。なので、老害のくせに性懲りもなく応募してみる事にしました。

まずFox Splitter。

URL

https://addons.mozilla.org/firefox/addon/fox-splitter/

Name

Fox Splitter

Description

Do you want to browse multiple webpages (ex. "English version" and "translated version") side by side? This can do it.

This provides ability to "split" a Firefox window to multiple ones, and manages them (grouped windows) like a large window with multiple panes. To "split" the window, "Split" button in the navigation toolbar is available. Otherwise, you just have to drag a tab to near the inner edge of the window itself, and stay there. Then a drop position marker will appear like the screenshot: https://static-cdn.addons.mozilla.net/img/uploads/previews/full/59/59710.png?modified=1309171529 Not only two panes, but also three, four, or more "panes" are available. Of course, when you resize a member window, others also fit to it like panes in a large window.

This is developed without Add-on SDK but based on my tiny framework named "Restartless", including customizable toolbar items, configuration dialogs, l10n, Firefox 3.6 support, and so on. https://github.com/piroor/restartless

あと、Back to Owner Tab。

URL

https://addons.mozilla.org/firefox/addon/back-to-owner-tab/

Name

Back to Owner Tab

Description

Have you met such a stressful situation?: You finished to read a webpage and want to back to the previous page, but you can't click the "back" button because it is disabled - yes, you were in a new tab opened from the previous page, so you have to close the current tab instead of clicking "back" button.

This provides ability to go back/forward across tabs/windows. Even if the current page is in the first (or last) entry in the history, the "back" (or "forward") button is still enabled. If you click the button, then the owner tab (or the "next" tab - it had focus before the "owner") gets focus.

This is developed without Add-on SDK but based on my tiny framework named "Restartless", including customizable toolbar items, configuration dialogs, l10n, Firefox 3.6 support, and so on. https://github.com/piroor/restartless

最後にさらに宣伝しておくと、先日発売されたオライリーのFirefox Hacks Rebootedには、GomitaさんによるAdd-on SDKを使ったアドオン開発のチュートリアルと、Add-on SDKを使わない再起動不要なアドオン開発での色々なテクニック・注意点のまとめの両方が収録されています。再起動不要なアドオンには興味があるけど、まとまった情報が無くて二の足を踏んでる……という方がもしいらっしゃいましたら、こちらの本を片手に挑戦してみるといいかもしれませんね。

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

Back to Owner Tab（親のタブに戻る）を「進む」に対応させた - Aug 30, 2011

親のタブに戻るで使ってる再起動不要なアドオンのテンプレートそのものに「無効化した状態でアップデートしたら勝手に有効になってしまう」という重大な不具合があったので、その更新も兼ねて、「進む」方向への対応を加えて肉リリースした（太平洋標準時）。

前のバージョンでは単純にタブの.ownerを見て戻る先を判断してたんだけど、これはタブのフォーカスが切り替わるとクリアされてしまうので、1回親のタブに戻ったらそれっきりだった。また、.ownerがクリアされてしまっては、「進む」がクリックされた時にどこに「進」めばいいか分からないし、仮に分かったとしても現在のタブから複数の子タブが開かれていた場合はどこに「進」むのが妥当かという判断がつかない。ということで、「進む」への対応はしてなかった。でも実際使ってたらうっかり「戻」ってしまった後にまた「進」みたくなるという場面が結構あったので、いずれは何とかしたいなーとは思ってた。

で、肉リリース目指してせっかくだから片付けとこうと思って手を付け始めたら、これが結構大がかりな事になってしまって、結局、タブ毎に固有のIDがあって、各タブが自分の親のタブの情報を常に持っていて、ついでに自分が最後にフォーカスされた時刻も持っている、というファットな実装になってしまった（ツリー型タブの初期のバージョンと同じくらいの情報を持ってることになる）。

それでどうなったかというと、前までは1回しか「親のタブに戻る」できなかったのが、何階層でも祖先のタブに「戻」って、その後また元見ていたタブまで「進」む、という事ができるようになった。タブの垣根を越えて透過的に「戻る」「進む」できるというのはかなり変な気分だ。横置きの普通のタブバーでやると、自分が今どのタブを見てるかわかんなくなるんじゃないだろうか。そういうわけで、これはツリー型タブとの併用をお薦めしておきたい（ツリー型タブとの併用時ならツリー構造として既に構築済みの親子関係をそのまま「戻る」「進む」に使えるというメリットもあるのです）。

マルチプルタブハンドラで、タブの選択で一部のタブがスキップされないようになった - Aug 30, 2011

マルチプルタブハンドラはタブの上でドラッグ操作をやると複数のタブを選択できるという物で、mouseoverとまmouseoutとかのイベントを拾ってそういう挙動を実現してるんだけど、mouseover/mouseoutのイベントが発火されない事があるせいで、タブを選択しようとして一部のタブだけ選択されなくてイラッと来る事が時々あった。具体的に言うと、例えばA, B, C, Dの4個のタブがあったとして、AからCまでの3個を選択したくてAの上でドラッグ開始してCの上でマウスのボタンを放した時に、AとCは選択されるのにBが選択されないという感じ。

期待されているイベントが発火されないのはFirefox自体のバグみたいなんだけど、こんなのもうどうしようもないじゃんと思って放置してた。そしたらtitoさん（Komodo EditやSeamonkey用のアドオンを作られている方で、僕のアドオンのいくつかにスペイン語ロケールを提供してくれてる）が「こうすればいいんじゃない？」という提案をして下さったので、プルリクエストで貰ったパッチを参考にもう少し改良した上で実装してみた。基本的な理屈としては、あるタブを選択する時に「直前に選択されたタブ」を保持しておいて、新しく選択されたタブと直前に選択されたタブの間にタブがあればそれらも選択されたものと見なす、というもの。この「直前」の判定基準にはtitoさんのパッチで提案されていた300ミリ秒という数値をそのまま使わせて貰った。

それで実際使ってみたら快適すぎワロタ。今までどれだけこのバグがストレスを産み出していたのか……　タイミングがちょうどよかったから肉リリースしておきました。自動アップデートで皆さんもこの快適さを味わうといいです。

あと、日本語環境向けの細かい変更で、タブを選択した時のメニューのラベルが「Close All」の直訳で「すべて閉じる」とかになってたのを「閉じる」のようにまず動詞が先に来るように直した。こうしておかないと、メニューに項目がずらっと並んだ時にぱっと見で判別できなくて困るという事が多かったので。

Fox Splitterを元の設計に戻して欲しい (Why Fox Splitter lost its functionalities in old versions: multiple panes in a window, not multiple windows?) - Aug 25, 2011

Q

Why did you remove the awesome functionalities from Fox Splitter 0.6 and replaced it with Fox Splitter 2? Fox splitter is now just a way to glue multiple instances of Firefox together.

I would like to ask you to remake the functionality of Fox Splitter 0.6.2009110501, perhaps as it as a function that can be enabled or disabled? Or perhaps just make the 0.6.2009110501 version workable on newer Firefox versions?

どうしてFox Splitter 0.6の素晴らしい機能（※訳注：1つのウィンドウの中を複数のペインに分割する機能）を削除してFox Splitter 2で置き換えたのですか？　今や、Fox Splitterは単に複数のFirefoxのインスタンスをくっつけて一緒に操作するだけの物になってしまいました……

Fox Splitter 0.6.2009110501の機能を復活させて、オプションで有効無効を切り替えられるようにならないでしょうか？　それか、単にバージョン0.6.2009110501を新しいFirefoxの上で動作するようにできないでしょうか？

A

I recommend you to try Tile Tabs or Tile View, if you want to split a window to multiple panes and don't want toolbar/tabbar for each pane.

Sorry, Fox Splitter never introduce "multiple panes in a window" feature in future releases. There are some reasons.

After I initially released the old Fox Splitter, I realized that each "pane" should have navigation toolbar for usability. So I actuary did it. However, much codes was required, it had too less maintainability, and it was strongly depended on codes of the specific version of Firefox. So I couldn't update the old Fox Splitter for 1.5 years.

During that time, similar new addons "Tile Tabs" and "Tile View" debuted. I hope that they can replace my old Fox Splitter. However, after I tried them, I couldn't become familiar with their concept. I thought that their "tiled view in a tabbrowser" is hard-to-understand.

Moreover, both "Tile Tabs" and "Tile View" didn't provide navigation toolbar for each pane. I realized that it was a unique feature of my old Fox Splitter and no other addon inherited the concept. I thought that I have to implement such an extension by myself if I want to use it -- no one does it for me except myself.

Yes, I decided to update Fox Splitter. And, I decided to drop functionality to split a browser window to multiple panes, because it requires huge codes and it is very hard to maintain for current rapid-released Firefoxes. I don't want to abandon the new Fox Splitter for a long time anymore. High maintainability (and compatibility) code is strongly required for me. The old Fox Splitter didn't have them and I cannot cover them by my crazy hacking time - now I have less time to do it.

もしあなたが分割されたそれぞれの領域のためのツールバーやタブバーを必要としないのであれば、Tile TabsかTile Viewを試す事をお薦めします。

申し訳ないのですが、Fox Splitterが「1つのウィンドウの中を複数の領域に分割する機能」を将来のバージョンで実装する可能性はありません。それにはいくつかの理由があります。

私は、Fox Splitterの最初のバージョンを公開した後で、実用性のためには分割後の各領域がそれぞれ専用のツールバーを持っている方が望ましいという事を実感しました。それで実際にそのような機能を実装しました。しかしそのためには非常に多くのコードを書かなければならず、コードの量が多いという事はメンテナンス性も低かったですし、さらに言うと、それらのコードは特定のバージョンのFirefoxに強く依存した物でした。そのため、私は旧Fox Splitterを更新し続ける事ができず、1.5年もの間完全に放置してしまっていました。

そうこうしている間に、Fox Splitterに似た新しいアドオンの「Tile Tabs」と「Tile View」が公開されました。私は、これらのアドオンが私のFox Splitterの代わりになってくれればいいと期待していました。しかしながら、実際にそれらを試してみると、私にはどうしてもそれらの設計コンセプトに慣れ親しむ事ができませんでした。それらがやっている「1つのタブブラウザの中でタイル表示を行う」というのは、直感的な理解が難しいアプローチなのではないかと、私には思えました。

それに加え、「Tile Tabs」と「Tile View」の両者とも、それぞれの分割された領域のためのナビゲーションツールバーを提供していませんでした。これに至って私は、それが旧Fox Splitterに特有の機能で、そのコンセプトを継承した他のアドオンはまだ登場していないのだという事を理解しました。そのような物を使いたいのであれば、自分自身で実装するしかないーー自分以外の誰もそういう事をやってはくれないのだ、と、私は思いました。

それで、私はFox Splitterを更新する事を決意しました。また、それと同時に、実現するために非常に多くのコードが必要になる上に、現在の高速リリース体制になったFirefox向けにそれをメンテナンスし続ける事は非常に難しいということで、1つのウィンドウの中を分割する機能を廃止する事も決めました。私はもうこれ以上、Fox Splitterを更新できないまま長い期間放置してしまうような事になってしまうのを望んでいません。高いメンテナンス性（そして互換性）を持つコードこそが、私の求めていた物でした。旧Fox Splitterにはそういう視点が欠けており、そういった問題を絶えず修正し続けるために狂ったように多くの時間を注ぐ事は、今の自分には不可能だとも思っています。