Latest topics 近況報告

ツリー型タブがあると遅くなるとかツリー型タブが重いとかその辺の話について - Sep 17, 2012

ツリー型タブが重いという声をたまに見かけるんだけど、そういうのを見かける度に「ほんとかなあ？」とついつい思ってしまう。

もちろん、素のFirefoxに対して余計な処理を加えるわけだから、そりゃあ、元の状態より重くはなると思う。でも、「重い」って言ってる人の言ってる「重い」は、なんというか、そういうレベルのことを言ってるわけではないって気がする。もっと鈍重な、全体的に動作がヤバイくらい緩慢になる、そういうのを指してる気がしてる。

で、そういう現象が起こるとして、本当にそれがツリー型タブのせいなのかどうか。ツリー型タブを使っている時と使っていない時とで、同じ数のタブを開いていて、同じ時間だけブラウジングした状態で、ツリー型タブがある場合だけ顕著に性能が劣化するのかどうか。というのが、この件で自分が一番気になっているポイントなのです。

何故僕はこうまで頑なに「ツリー型タブが原因で遅くなっているのだ」と素直に認めようとしないのかというと、基本的にツリー型タブはブラウザのコンテンツ領域や履歴にはタッチしないように設計しているつもりなので、「コンテンツ領域に起因するメモリリークがある」とか「履歴を消去したら軽くなった」とかの報告があるという事自体が、どうにも不可解なのです。

実際、about:memoryではタブ毎にメモリの使用状況を確認できますが、「about:memoryを見ると、メモリが解放されていないことが分かる」と言われた再現条件をこちらで試行しても問題が再現せず、その後報告者の環境でもツリー型タブだけをインストールした状況では問題が再現しなくて、どうやら他のアドオンがこの問題の原因になっているのではないかという話になったこともありました。

ツリー型タブがあるとタブを開く数が増える＆1つ1つのタブの生存期間が長くなる傾向があると思うので、他のアドオンやFirefox自身が潜在的に抱えてはいるものの普段の利用では無視できる程度だったという問題があったとしたら、それらがより顕在化しやすい状態になるとは思います。例えばあるアドオンを入れていると全体の動作が0.1秒遅くなるとして、5つくらいタブを開いている状況ではそれが気にならなかった。でも、ツリー型タブを入れてタブを50とか開きっぱなしにしていると、些細な重さでもそのまま×50されるから、シャレにならない重さになる。こういう事は十分にあり得ます。でもツリー型タブ単体でそういう事が起こるとはどうしても自分には考えにくいのです。

「コンテンツ領域への参照を残しているせいでメモリリークが発生する」というのは自分もアドオン開発初期にはよくやらかしていたミスなので、かなり後の方になって開発したツリー型タブの頃にはそこらへんのことは想定に入れられるようになっていて、多少速度を犠牲にしてでも安全になるように、だいぶ気をつけて設計したという認識があります。「そこまでやらんでもええんちゃうん」って所まで偏執的にやってることすらあります。Firefox本体のコードでもaddEventListenerした物をremoveEventListenerせずに放りっぱなし（多分ガーベジコレクション任せ？）になってるのとか見ると、怖いなーって思ってしまうくらいです。

その一方で、僕は「これこれこのアドオンと衝突してるんだけど」という報告を受ける度にそのアドオンのソースを見るという事がこれまで結構あったのですが、ソース見てげんなりすることが割とありました。これメモリリークするやろ、とか。で、そういう問題を解決しようと思ったら、根本的なアーキテクチャの変更が必要だったりして。そういうとこまで見だすときりが無いし、大体それは僕の領分でもないので、ツリー型タブとの衝突の原因になってるとこだけ見てあとは見て見ぬふりしてるんですけども。

そういう惨状を見てるから、僕の心情としてはついつい、まず最初に他の原因の方を疑ってしまいます。それらの可能性がなくてちゃんと明らかに「ツリー型タブが原因だ」と断言できる、という所にまで絞り込まれてないと（はい。ほんとにツリー型タブが原因で問題が起こってる可能性も、もちろんあるとは思ってます。そこまで完全否定はできないです。）、調べようという気になかなかなれないです。これって、思い上がりすぎですかね？

あと、それとは全然別の話として、ツリー構造が何らかの理由で壊れてしまうせいで、無限ループが発生してフリーズしてしまう……という事は時々起こるみたいなので、そういうのはもう完全にツリー型タブの責任なので今後も粛々と直していきたいとは思ってます。

いずれの場合にしても、メンテナンスに十分に時間を割けない現状では「ツリー型タブのせいで問題が起こってる、かもしれない」という段階では動けなくて、「間違いなくツリー型タブのせいで問題が起こってて、この手順で100％再現できる」という所まで絞り込んでもらってることが、こっちで対処できるためには絶対に欠かせない条件という感じです。できれば「この部分が問題になっている」という所まで明らかにしてもらえてると嬉しいし、もっと言えば修正パッチをpull requestでもらえるのがベストなんですが。

それから、何と言おうとツリー型タブを入れてFirefoxの動作がおかしくなり、ツリー型タブを削除したことでこれらが解決されたことは事実なのです。 という風な話はもう何度あったか覚えてられないくらいにあって、GitHubのIssue Trackerを探してもゴロゴロでてくるんだけど、詳しく聞いてみると大概は他のアドオンとの衝突です（全部がそうだというわけではないですが、感覚的には、そうである場合の方が多かったという印象です）。こういうのも、じゃあどのアドオンと衝突してるのかという所まで明らかにさえしてもらえれば、何か手の打ちようが出てきくる可能性がありますので、より快適な生活を望む場合には、衝突の解消に協力してもらえたらなーって思います。

セッションの復元とツリー構造の維持 - Aug 07, 2012

ツリー型タブを3ヶ月ぶりに更新した。

地味な修正が多い中で特に地味な修正だけど、セッション復元でツリー構造が壊れるという問題について一定の改善を見られたのではないかと思ってる。実際に効果があったのかどうかは、今後同様のバグ報告が減るかどうかで見るしかない。

何故ツリーが壊れるか、という事の前にそもそもツリーが壊れるってどういう事やねん、という話なんだけど、ツリー型タブを使っててごく希に、「リンクから新しい子タブを開いても子タブにならない」とか「親にあたるタブには折り畳みのためのつまみが表示されているのに、子になったはずのタブはインデントされておらず、つまみをクリックしても子になったはずのタブが折り畳まれない」とかそういう怪しい挙動になる事があった。

何故そういう事が起こるのか。これはタブの管理方法に理由がある。

ツリー型タブでは、個々のタブに一意なIDをあらかじめふっておいて、tab.setAttribute(TreeStyleTabService.KPARENT, parentTab.getAttribute(TreeStyleTabService.kID)) とか tab.setAttribute(TreeStyleTabService.kCHILDREN, childTabs.map(function(aChild) { return aChild.getAttribute(TreeStyleTabService.kID); }).join('|')) とかいう感じにIDの文字列をキーにして互いの関係を保持している。親のタブや子のタブを取得する時は、TreeStyleTabService.getParentTab(tab) とした時にその中で tab.getAttribute(TreeStyleTabService.KPARENT) して取得したIDを使って（DOM3 XPathなどで）実際の要素を改めて取得するという風になってる。何故こうしたかというと、

• タブの要素ノードに直接 tab.parentTab = parentTab のようにしてしまうと、うっかり参照を消し忘れたらいつまで経ってもメモリが解放されないんじゃないか、という心配があった。（意図しない事態の発生を防ぐため）
• 実際には setAttribute() するのと同じタイミングで SessionStore.setTabValue(tab, TreeStyleTabService.kPARENT, parentTabId) のようにしてセッションに情報を複製しており、クラッシュ時のツリーの復元などに役立てている。（ツリー構造の永続的な保存のため）

といった理由があってのことだった。

これはそれなりに堅牢なやり方なはずだと思ってたんだけど、実際にできあがってからJavaScriptデバッガでプロファイリングしてみたら、IDの文字列からタブの要素ノードを探すという処理が呼ばれる回数が突出して多くて、それが結構無駄な待ち時間を増やす元になっているらしかった。それで、もう少し高速に動作するような仕組みを後から加える事にした。setAttribute(TreeStyleTabService.kID, id) するのと同じタイミングで、gBrowser.treeStyleTab.tabsHash[id] = tab; としてハッシュテーブルを作っておき、それ以後はそちらだけを参照するという、ごくシンプルな物だ。

上記のおかしな挙動は、このハッシュテーブルが原因だっていた。このハッシュテーブルの仕組みが上手く働くためには、「ハッシュテーブルに入っていないタブはない（すべてのタブがハッシュテーブルで管理されている）」という前提が必要になる。もし万が一何らかの理由でハッシュテーブルの管理から漏れてしまうと、そのタブはAPI経由では永久に見つけられないことになってしまう。そのタブを親として子タブを登録する、という風な事はできるのに、その子タブに保存された情報から親のタブを探そうとしても、ハッシュテーブルに無いタブだから見つけられない。こういう不整合の発生は考慮に入っていなかったので、親子関係に基づくインデント幅の調整などの処理が中途半端な所で止まってしまって、上記のような色々と不可思議な現象が発生していた。

色々調べた結果、大量のタブが一気にセッション復元された時に「現在のタブ」になっていたタブが、このハッシュテーブルの管理から漏れてしまうことがあるようだという事が分かった。なので、そのような場合もちゃんとハッシュテーブルに入るようにした。これによって、手元で再現性100％だったケースについては問題が起こらないようになった。これまでに報告があった全ての問題がこれと同一の原因かどうかは不明だけれども、今までよりは問題が起こりにくくなったという事は言えると思う。

あと似たような問題で、タブの復元のタイミングによっては「ツリー構造だけの高速な復元」ができなくなるという現象も起こっていた。ツリー型タブが完全に初期化されるよりも前にFirefoxのセッション復元の仕組みによってタブが復元されていた、という想定外の状況が発生していて、それで色々な前提が崩れてしまっていた。理屈から言ってなんでそうなるのかがてんで分からなくて、どうにかしてタブが復元されるよりも前のタイミングに割り込みたかったんだけど、どうも無理っぽかったので、既にタブが復元されてしまっていた場合でもちゃんとそれらのタブを「後から初期化」するようにした。

そういう地味な修正ばかりが入っている版です。

The priority policy of my addon projects - May 10, 2012

In recent days, I discussed on the issue about scrolling of the vertical tab bar. It made the priority policy about my addon projects clear, again. So, let's sum up them.

• I assign the highest priority to issues I actually annoyed. Most projects were started because I wanted to use such addons. This is the main motivation to continue developing for me. In other words, when I suffer from a bug in my daily use, I'll fix it prior to other bugs, even if the mine is just trivial and the yours is very serious. After that, if I have time good enough, I'll research and fix your issues. If I've never used the feature (and I never use it in the future), then there is extremely low feasibility rating.
• I'm negative about adding new features (especially digressive features) to existing addons. Because I currently have no plan to switch to other browsers (Google Chrome, etc.), I want to keep codes easy to follow up to future releases of Firefox. Even if the new feature looks simple, it can cost much time for maintenance in the future chronically. Long term sustainability is prior to short term convenience, for my projects. I'll reject requests which can lose maintainability or independency of the project, even if it is very useful feature, fixing serious bug, and so on.
• I think that any addon shouldn't break features of Firefox itself without any apparent reason. For example, because the tab bar is automatically hidden in the full-screen mode (F11 key) by default, the vertical tab bar also should be done. If my addon breaks Firefox's default behavior unexpectedly, then I'll make effort on fixing it. However, if the issue is not introduced by my addon, then I often step back from it.

Because currently I have less time to develop addons, I have to apply these policies strictly. Actually, in recent days, I spend just a few days of my time per a month for my private development. Sadly I have to keep many requests pending.

However, codes of my addons are licensed under open source licenses. For example, Tree Style Tab is licensed under GPL/LGPL/MPL. You can fork, develop, or re-distribute any project based on my codes, by your hand. Your version can be better alternative for people who suffered from the issue ignored by me. (And, if it is enough reasonable, I possibly merge your changes to my repository.)

Fox Splitterを更新した - Apr 23, 2012

バージョン0.6系（旧版）と2.x系（現行バージョン）の両方とも更新した。

バージョン0.6系の方は、前に書いた2.x系への自動アップデート機能の追加だけで、他は何もいじってない。AMOからインストールした人が2.x系に自動アップデートされないという問題への対処のためだけに作ったバージョンなので、AMOにしかアップロードしてない。基本的にこっちはもう終了したバージョンということでよろしく。

2.x系の方は、最近になってUbuntu上でヘビーに常用し始めるようになって色々気付いた問題を修正したのと、僕の使い方で「ああこういう機能欲しいやばい（ないとめんどい）」と思った機能を追加した。

修正の方で特に大きいのは、「グループ化されたウィンドウの1つを移動した後に他のウィンドウをそれに併せて移動する」という部分の改善だと思う。

GNOME2のワークスペース切り替えの時はそこまで酷いことになってなかったんだけど、Ubuntu 11.10にアップデートして3×3のワークスペースを使うようにし始めた（これ多分GNOME3の機能ですよね？）ところ、全く使い物にならないレベルでグループの配置が壊れるようになってしまった。GNOMEのワークスペース切り替えは、少なくともFirefoxの中から見た時には、各ウィンドウの座標を固定してビューポートの方だけを移動させるんじゃなくて、ビューポートの座標の方を固定して全部のウィンドウの座標をぐりぐり動かしているように検知されている。なので、ワークスペース切り替えの時に全部のウィンドウのscreenX/screenYの値が変わってしまう。それで、それぞれのウィンドウがてんでバラバラに「グループの中のウィンドウが1個動かされたから他のウィンドウも再配置しよう」という事を始めてしまってシッチャカメッチャカになっていた。

「グループ化されたウィンドウ全部が相対座標を保ったまま一度に移動されたので、再配置の必要なし」とかの判断をちゃんとするようにすればよかったんだけど、僕の頭で思いつくやり方だとどーにもうまくいかんかったので、諦めて安全確実だけどちょっと重い方法でウィンドウの移動→グループ全体の再配置を行うようにした。普通にウィンドウをドラッグで移動した時とかのレスポンスは悪くなったんじゃないかと思うけど、背に腹は代えられない。

新機能は、「グループ化されたウィンドウの1つでPanoramaを使った時に、グループ全体の大きさまでそのウィンドウを一時的に広げる」という機能が元々あったのを、Panoramaの時以外にも使えるようにした（ついでに、詰めが甘かった所を色々直した）という物。何でこういう物が欲しかったかというと、

1. 僕は今Ubuntuのワークスペースの1つをFox Splitterで3分割したFirefoxのウィンドウ専用に割り当てている。
2. 分割後のそれぞれのウィンドウには、別々のプロジェクトのRedmineのチケット一覧を表示している。
3. それぞれのプロジェクトでチケットを追加する時は、その分割されたウィンドウの中でやっている。
4. Redmineはある程度の大きさのウィンドウで表示される前提でレイアウトが組まれているので、狭いウィンドウの中では非常に使いにくい。
5. なので、チケットを書いたり詳細を読んだりするときだけそのウィンドウを大きくして、終わったら元の大きさに戻す（そうしないと他のウィンドウのRedmineが見えないから）という事をよくやっていた。

という使い方をしていて、いいかげんいちいち自分でリサイズするのが面倒になったから。

今のFox Splitterは、全体を管理する大きなウィンドウのような実体が無い状態で各ウィンドウをあたかも1つのグループの下に属しているかのように協調して動作させる、ということをやっていて、作ってる側の自分としては、頭を抱える部分も多いけれども「元々Firefoxにある物だけを駆使してどこまでできるか？」ということを追及するある種の挑戦というかパズルに挑んでいるような感覚もあって、そういうことを効率よくやるためには結局2分木でやるのが安全確実なんだなあとか色々と気付かされた所があって、ノウハウ的にも自分のやってきたことの集大成になってるんだけど、エンドユーザとしての使い勝手は多分旧版のFox Splitterに比べると劣化してると受け取られることの方が多そうで、報われないことに一生懸命になってるなー感が自分である。

とはいっても、自分で使う分にはとりあえずこれだけ動いてくれれば十分だし、旧版の設計で今後もずっと自分でメンテナンスし続けるのは絶対に無理だし、もっといいやり方が見つかるまでは、この路線を変えることは多分無いと思う。

Ez Sidebarを数年ぶりに更新した - Apr 07, 2012

bit.ly/I4YzVe bit.ly/I4YAbC Ez SidebarのFirefox 11対応は僕の手では不可能だけど、技術的には出来そうということは調べはついたので誰かやってください。

— Piroさん (@piro_or) 4月 5, 2012

とかなんとか発言した舌の根も乾かないうちにEz Sidebar 4.0.2012040701を公開した。実験的にやってみたら案外あっさりできたので、その勢いで完成まで一気に。実質的にほぼ0からのスクラッチで、基本設計が全く別物になっていてコードの共有部分はほとんど無い。

旧版ではサイドバー用のウィンドウを物理的に（DOMツリー的に）別ウィンドウとして開いていて、パネル内のスクリプトに対してどうやってブラウザウィンドウの中にあるように見せるかという所が技術的な鍵だった。例えばwindow.parent.gBrowserにアクセスされたら、最も手前にあるブラウザウィンドウを探してきてそのgBrowserを返す、みたいな感じで。そういう強引なことをやってたから、つくづく、よくあんなんで動いてたなという感じだ。

今回の再実装では、根本的な考え方は至極単純で、ウィンドウの内容が初期化されるタイミングで<panel>の中にサイドバーのボックスを丸ごと移動して、以後はその<panel>を「別ウィンドウに切り離されたサイドバー」として表示している。これだとサイドバーは相変わらず元のウィンドウのDOMツリーの中に存在しているから、パネル内のスクリプトから見た時に普通に親のフレームとしてFirefoxのウィンドウにアクセスできるし、Firefoxのウィンドウの側からもパネルの内容を普通にサブフレームとして認識できる。Firefoxのウィンドウが複数ある時は最前面のウィンドウの<panel>だけを表示しておき、ウィンドウが切り替わったタイミングで同じ位置・同じ大きさに<panel>を表示する、という事をやってるので、見た目的には1つの<panel>が個々のFirefoxのウィンドウとは独立して存在しているように見えなくもない。他にも、ドラッグ操作での移動とかリサイズとか、ただの<panel>をウィンドウっぽく動かすために細かい所で違和感が出ないように色々やってる。

何故旧版では<panel>を使わなかったのかというと、やりたくてもやれなかったんですよ。サイドバーは一種のインラインフレームなんだけど、確か昔は<panel>の中にインラインフレームを置くとまともに動作しなかったと思う。そういう細かい技術的な障壁が当時は色々あって、Ez Sidebarのような事をどうしてもやりたいとなると、旧版のようにダーティなハックをたくさん仕込まないといけなかった。それが今では、「こう書いたらこう動いて欲しいよね」という書き方をすればだいたいフツーに動いてくれるわけですよ。隔世の感だ。

あと、バージョン3.2（1つ前のバージョン）にあった機能を全部引き継いでるわけではなくて、というかサイドバーをメインウィンドウから切り離して表示する機能以外は全部バッサリ切り捨てた。All-in-One Sidebarのような有名所のアドオンが既にそういう機能を持ってるみたいだから、わざわざ同じ機能を作らなくても、そっち使えばいいじゃんという話です。Ez Sidebarは、他のアドオンが提供してくれない機能だけに絞って提供した方が意義があるはず……と思って。

過去にこのアドオンの名前を「Sidebar Window」から「Ez Sidebar」に変えたのは、サイドバーの切り離し以外の機能も色々付けたからだったんだけど、今回のリリースで機能的には最初の物より低機能な所に逆戻りしてしまった。皮肉な結果だ。

Fox SplitterのせいでユーザのFirefox 3.6からの移行が進まないって言われた件 - Apr 02, 2012

Linuxでwmctrlを使うようにしたバージョンのFox Splitterを今日付で公開した。

なんだかんだで最近腰が重いんだけどその重い腰を上げてリリースのための作業をやろうと思った背景の1つには、Mozillaの中の人からメールで表題の件について連絡があったからだ。既知のバグがあってmasterでは直ってるのにリリースされていない、という状況ではそのメールに返信するのが憚られる……と思って、慌てて細かい所を直してリリースしたというわけ。これも罪悪感駆動開発な気がする。

Fox Splitterのユーザが古いバージョンを使い続けている最大の理由は、AMOでFox Splitter 0.xから2.0への自動アップデートが行われないからじゃないかと思ってる。諸々の事情でFox Splitter 2.0では旧版からアドオンのIDを変えないといけなかったので、AMOのサイト上ではFox Splitter 2.0と0.xが別々のアドオンとして登録されてて、Fox Splitter 0.xのユーザにはFox Splitter 2.0が自動アップデート経由で提供されない。2.0への移行は、完全にユーザの自由意志に任せざるを得ないという事になっている。使い勝手がどうとか以前に、勝手にアップデートが下りてくるかこないかがネックになってるっていう予想だ。

強権的手段として、「単にFox Splitter 2.0を自動的にインストールして、その後Fox Splitter 0.xを削除する」というだけの内容のアドオンをFox Splitter 0.x最新版としてアップロードすれば、Fox Splitter 0.xから2.0への移行を強制することはできるけど……2.0の方には否定的なレビューが多く付いていて評価も低い（旧版は星2つ以下は15％なのに対し、新版は星2つ以下が57％……まあ母数が圧倒的に少ないから統計的にはあんまり意味がないかもなんだけど）という現状を見ると、そこまでやっちゃっていいっていう自信をまだ持てずにいる。

4月4日追記。Mozillaの中の人から「ちょうどそういう（Fox Splitter 0.x系の新バージョンとして、Fox Splitter 2への自動アップデート機能を含んだ物をリリースするという）方法について提案しようと思ってた所だった」的なレスポンスがあったので、春の嵐で早退したのをいいことに頑張って書いてみたんだけど、死ぬほどめんどかった。

Fox SplitterのLinuxでの挙動の改善と、Mac OS Xで残された課題 - Mar 25, 2012

Fox SplitterをWindows以外で使った時に 実にパネェ感じでストレスフルな挙動を示す件について、とりあえずLinuxではちょっとだけ改善できた気がする。

要点を先にまとめておくと、こういうことだ。

• Windows上では以前から、ウィンドウの1つが選択されて最前面に来たら、グループ化された他のウィンドウもそれによって「押し上げられ」て最前面に来る、という挙動になっていた。
• でもFirefoxの仕様上の制限で、LinuxとMac OS Xではそれができていなかった。
• 今回、Linuxではwmctrlを呼び出すことによってWindows上と同じような挙動を再現できるようになった。
• Mac OS Xで同じ事ができるのかどうかは分からないままである。
• JSDeferredはやっぱり素晴らしいです。

以下、背景も含めた詳しい話。

続きを表示する ...

ツリー型タブでタブのツリー構造を高速に復元できるようにしたり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本体のセッション復元機能に勝ってる部分、ありますか？　ないですよね？　いやよく調べないまま書いてるんだけどさ。

再起動のいらないアドオンのコンテストが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を使わない再起動不要なアドオン開発での色々なテクニック・注意点のまとめの両方が収録されています。再起動不要なアドオンには興味があるけど、まとまった情報が無くて二の足を踏んでる……という方がもしいらっしゃいましたら、こちらの本を片手に挑戦してみるといいかもしれませんね。

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

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

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

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

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