Latest topics 近況報告

ツリー型タブとマルチプルタブハンドラとHTML5のドラッグ＆ドロップ - Dec 02, 2010

Tree Style TabとMultiple Tab Handlerのドラッグ＆ドロップ周りのコードを色々書き直した。

Tab Utilitiesとの衝突

発端は、「Tab Utilitiesと一緒に使うとタブのドラッグ＆ドロップが期待通りに動かない」という報告だった。しかし、「また衝突かよー」と思いながらメールの内容を読むと、想像していたのとはちょっと状況が違った。

僕はてっきり、Tab Utilitiesのイベント処理とツリー型タブのイベント処理がかちあって変な事になってるんだとばかり思ってたんだけど、そうではなくて、Tab Utilitiesが提供する「複数のタブを選択してまとめてドラッグ＆ドロップする」機能で複数のタブを1つのタブの上にドロップしても、選択されていたタブのうち1つしかドロップ先のタブの子タブにならない、という状況だった。その人はすでにTab Utilitiesの作者にも問い合わせていたようで、Tab Utilitiesの作者の回答に「ツリー型タブにマルチプルタブハンドラのためのコードしか含まれていないのがそもそもの問題だ。ツリー型タブの方で修正してもらってくれ。」みたいなコメントがあったそうだ。

それでTab Utilitiesを見てみたら、確かに複数のタブを選択する機能があったんだけど、その時のタブの情報の受け渡しにHTML5のドラッグ＆ドロップのイベントの複数のデータの指定の仕組みが使われているようだった。

• マルチプルタブハンドラを最初に作ったときはまだこんなAPIは無かった。
• タブのドラッグ＆ドロップの実装になるべく介入したくなかった。タブがドロップされた時に、そのタブが選択状態だったら、他の選択されているタブも一緒にドラッグされることが意図されていたと判断して、後から他のタブも追従して移動させる、という設計にしていた。

という事情があって、マルチプルタブハンドラではドラッグ操作のイベントそのものには介入しないようにしてたんだけど、Tab Utilitiesがそういう事をやってるんだったら、「複数タブのドラッグ操作」に特化したアドオンであるマルチプルタブハンドラが黙って見てるわけにはいかない。なので、マルチプルタブハンドラではバージョン0.6から、ついでにツリー型タブもバージョン0.11.2010120101から、タブをドラッグ＆ドロップするときはドラッグしようとしているすべてのタブをデータトランスファーに渡すようにした。ついでにドラッグフィードバックイメージも自前で生成するようにして、複数タブのドラッグ時はドラッグ中のすべてのタブのサムネイルを重ねて表示するようにしてみた。

それで「ああやっと時代に追いつけたわ」と安心してたんだけど、Windowsでテストしてみたら、せっかく生成したドラッグフィードバックイメージがぜんぜん表示されないんでやんの。どうも、Windows版のFirefox 3.6以前は、mozSetDataAt()で複数のデータを指定するとドラッグフィードバックイメージが表示されないというバグがあるようだ。Ubuntu上のFirefox 3.6や、Windows上でもMinefieldでは問題なかったんだけど。頑張りの報われなさに切なくなった。

ツリー型タブのリファクタリング

ツリー型タブの場合は、タブのドラッグ＆ドロップでツリーを編集する場合があるから、マルチプルタブハンドラみたいにTabMoveイベントをトリガーとして後から必要な処理を行うということはできなかった。なので、Firefox自身のドラッグ＆ドロップの処理に介入する形の設計にせざるを得なかった。

その後HTML5のドラッグ＆ドロップのAPIが実装されて、Firefox 3.5ではFirefoxのタブのドラッグ＆ドロップのためのコード自体もそれをベースに書き直された。これはまだFirefox 3.0と同じようなやり方でドラッグ＆ドロップの処理に介入できる余地があった。

しかしFirefox 4ではタブのドロップとかドラッグオーバーとかの処理がXBLのイベントハンドラの中にベタ書きされるようになってしまって、メソッドの中に処理を注入するやり方ではドラッグ＆ドロップの操作に介入できなくなってしまった。なので、仕方ないからdragstartとかdropとかのイベントにキャプチャリングフェーズで割り込んでツリー型タブの側で全部自分で処理するようにした。

という経緯があって、結果的にツリー型タブのドラッグ＆ドロップ周りの処理はFirefox 3.0向けとFirefox 3.5～3.6向けとFirefox 4向けとで3種類の方法が同居してかなりシッチャカメッチャカな状態になっていた。あとタブバー自体のドラッグ＆ドロップの処理もあって、それぞれがあちこちに散らばっててだいぶ訳のわからんことになってた。

そんな状態だったから、昨日のリリースでは案の定リグレッションしてドラッグ＆ドロップが盛大にぶっ壊れてた。これはもう駄目かもわからんねと思ったので、Firefox 3.0向けのコードを全廃したついでにFirefox 3.5～3.6に対してもFirefox 4向けのやり方を使うようにして、ドラッグ＆ドロップのコードを専用のクラスに集めて整理することにした。

安定性とメンテナンス性を取った結果、タブのドラッグ＆ドロップのイベント処理はFirefox本体のものを完全に無視する形になっているので、他のアドオンとの機能の両立という点では残念なことになっているかもしれない。タブのドラッグ＆ドロップに介入するためのきちんとしたAPIが整理されていれば、こんな思いをしなくて済むのになあ。

pinTab()、unpinTab()への対応 - Jun 27, 2010

• Bug 563730 – Create "tab-like" sticky buttons for frequently used web applications
• Bug 574487 – Add option to pin tab from tab's contextual menu

このへんのパッチが投入されて、gBrowser.pinTab()とgBrowser.unpinTab()というメソッドが実装された。 pinTab()にタブを渡すとそのタブが他のタブの左側に寄せられて、unpinTab()に（pinnedな）タブを渡すと元に戻る。ぶっちゃけアレですね、Chromeの似たような機能のパクリですね。

この時、タブはスクロールボタン（左向き三角のボタン）よりもさらに左に表示されるようになるんだけど、これは一体どうやって実現されてるのか。実は、CSSで非常にトリッキーなことをしている。pinTab()に渡されたタブはpinnedという属性の値にvalueが設定されるんだけど、この時、.tabbrowser-tab[pinned="true"]なタブはposition:fixedに設定されて、通常の描画フローから切り離される。その上で、スクロールボックスの左にすべてのpinnedなタブの幅の合計と同じだけのマージンを設けて、pinnedなタブ1つ1つにはネガティブマージンを設定してそれらしい位置に表示する……という感じ。moveTab()の中とかでタブの状態を見て処理を分けていて、pinnedなタブはpinnedじゃないタブの中には移動できないし、その逆も然り。原稿のコードに対する最小限の変更でそれらしい挙動を実現するようにしている。よう思いつくな、こんなの。

大抵の既存のアドオンは影響を受けないはずなんだけど、タブ周りで凝ったことをしてる奴は、下手したら全滅しそうな気がする。というかツリー型タブなんかはお話にならないのが目に見えてる。なのでちょっと頑張ってみた。

• pinnedなタブのレイアウトの処理。改行とか。
• pinnedになった時、自動的にツリーから解放するとか。

結果。 最初は単に、pinnedなタブのレイアウト処理の所のX軸とY軸を入れ換えるだけにしてみたんだけど、それだと縦置きタブバーの場合は無駄な領域がメチャメチャ増えるだけだという事が分かったから、「タブが小さくなる」という所を優先して、24×24固定サイズでアイコンを並べられるだけ並べる（1行に収まらなければ改行する）という風にした。見た目は……あんまり良くないね。すんません。

縦置きしたタブバーとpinnedなタブの相性はすこぶる悪い。結局全部ツリー型タブの方で作り直すのに近い状態になってしまった気がする。でもまあ挙動としてはそれなりに違和感のない状態に落ち着いた。

これからまた実装に仕様変更が入らないことを祈るばかりだ。実装の仕方自体が変わってしまうなら、今回のこの作業はまるっきり無駄になってしまうから。

マルチプルタブハンドラでタブのURIをコピーする時のフォーマットをカスタマイズできるようにした - Jul 20, 2009

マルチプルタブハンドラではタブを選択した後に「すべてのURIをコピー」で選択したタブのURIをコピーすることができて、その時の形式を「URIだけ」「タイトルとURI」「HTMLのリンク」の3種類から選べるようになってたんだけど、今回のバージョンアップで、ここにさらにユーザが好みの形式を追加できるようにしてみた。ついでにマイナーバージョンも1つ上げてみた。

プレースホルダにはCopy URL +と同じものを利用できる（ツールチップの説明には書いてないけど%LOCAL_TIME%と%UTC_TIME%も使える）。自分は以下のものを追加して使ってる。

HTML Link List

<li><a href="%URL_HTMLIFIED%">%TITLE_HTMLIFIED%</a></li>

Markdown

[%TITLE_HTMLIFIED%](%URL_HTMLIFIED% "%TITLE_HTMLIFIED%")

Markdown (list)

 * [%TITLE_HTMLIFIED%](%URL_HTMLIFIED% "%TITLE_HTMLIFIED%")

RD

((<%TITLE_HTMLIFIED%|URL:%URL_HTMLIFIED%>))

RD (list)

 * ((<%TITLE_HTMLIFIED%|URL:%URL_HTMLIFIED%>))

Retrospectiva

[[%TITLE_HTMLIFIED%|%URL_HTMLIFIED%]]

Retrospectiva (list)

* [[%TITLE_HTMLIFIED%|%URL_HTMLIFIED%]]

ツリー型タブとマルチプルタブハンドラのAPIドキュメントの追加 - May 16, 2009

not enough memory - snj: 最近，Firefoxはもっと拡張間で連携プレーした方が良いんじゃないかって思ってきた．...

リンク先に書かれてる話からは少しズレる。どちらかというとこの前書いた互換性の話の方だ。

アドオン同士で連携するには、機能が使いやすくまとまってるということが当然必要だけど、それだけでなく、外部から安心して使えるということも非常に重要だと思う。公開されていて、今後のアップデートでも後方互換性が保証されていないと、安心して使えない。「ソースを掘り返してこういう機能を見つけたから使ってみてるけど、これって知らんうちに削除されてしまったりしないか？」という不安があってはいけない。機能が「今のバージョンにあるかないか」ではなく、「今後もあり続けるのかどうか」が重要だと思う。

ツリー型タブは以前からいくつかAPIを公開してはいたけど、基盤になる処理をもっと公開APIとして表に出すことにした。公開した物は原則として後方互換性を維持していく方針でいる。

• ツリー型タブの公開API

マルチプルタブハンドラの方も地味にAPIを整備している。

• マルチプルタブハンドラの公開API

もう僕は疲れたんで、この辺使ってよろしくやってくれってことで……

他のアドオンと連携しやすくするためのライブラリを作ってみた - May 13, 2009

マルチプルタブハンドラについてRockridge氏ほかから「メニューをカスタマイズできるようにしてくれ」という要望が挙がっていたのだけれども、Menu Editorという素晴らしいアドオンがあるのに自前で同じような機能を再実装するのは徒労感しか無いなあと思ったので、開き直って、マルチプルタブハンドラの設定ダイアログを以下のようにしてみた。

• Menu Editorがインストールされていなければ「Menu Editorをダウンロードする」リンクを表示する。
• Menu Editorがインストールされていれば「Menu Editorの設定を開く」ボタンを表示する。

Menu EditorのAPIをよく分かってないので（ていうかそもそも公開APIなのかどうかも知らない）、タブ選択時のメニューをカスタマイズできるようにするためにちょっと強引な方法を使ってる。

で、同じようなこと（他のアドオンの有無を調べた上で設定を開く）を何度も書きたくなかったので、設定ダイアログに加えた変更の要点を他のアドオンと連携しやすくするためのライブラリとして分離してみた。

if (window['piro.sakura.ne.jp'].extensions.isInstalled('my.extension.id@example.com') &&
    window['piro.sakura.ne.jp'].extensions.isEnabled('my.extension.id@example.com'))
    window['piro.sakura.ne.jp'].extensions.goToOptions('my.extension.id@example.com');

アドオンがインストールされているかどうか・有効か無効かを調べるだけならFUELで事足りるので、あまり使い出がないといえば使い出がない。まあThunderbird 2あたりでだったらニーズがあるかもだけど。

ちなみにFUELで書く場合、アドオンがインストールされているかどうかはApplication.extensions.has('my.extension.id@example.com')、有効か無効かはApplication.extensions.get('my.extension.id@example.com').enabledで分かる。設定ダイアログのChrome URLを調べるAPIはなくて、それでこのライブラリを作ることにした次第です。

マルチプルタブハンドラのAPIを使って貰えて嬉しかったという話 - May 10, 2009

感謝されても喜べないとか書いたけど、マルチプルタブハンドラのAMOでのレビューでAPIのことを誉められたのは、最近あった事の中では特に嬉しいと感じた出来事だ。

マルチプルタブハンドラは「複数のタブをまとめて操作する」機能を提供するアドオンだけれども、公開して多分すぐくらいから「こんな機能も付けてくれ」「あんな機能も付けてくれ」「このアドオンと連携してくれ」とかそんな感じの要望が出たと思う。そうなる事は最初から結構想像できていて、だから、タブの選択状態の制御や選択状態によるタブの取得といった事をできるAPIを開発初期から公開していた。他のアドオン作者の人がこれを見て、マルチプルタブハンドラ用のコードを組み込んでくれたら嬉しいなあ、という風に思っていた。

しかし実際には、MozillaZine Forum（本家の方）で宣伝するわけでもなく、AMOに同じだけの情報を載せられるでもなく、せいぜい分割ブラウザやツリー型タブなどの自作アドオンで細々と使う程度だった。このまま誰にも知られずに終わってしまうんだろうなあ、と思っていた。

なので、Paolo Amadini氏のこのコメントは非常に嬉しかった。

For developers, MTH provides a programming interface that makes it really easy to add new functions that work on multiple tabs; I used this interface in MAF, to provide an easy way to save multiple pages in a single file. （開発者向けに、MTHは複数のタブのために働く新しい機能を非常に簡単に追加できるようにするプログラミングインターフェースを備えている。複数のページを1つのファイルに簡単に保存できる手段を提供するために、私はMAFでこのインターフェースを使った。）

そこに目を付けて貰えた事が嬉しかっただけでなく、MAFという（僕にとっては）ずっと技術的に凄い事をやっているアドオンにマルチプルタブハンドラのためのコードを含めてもらえたということが、嬉しかった。今まで他のアドオンとの連携といえば、ずっとマイナーで世界の隅っこで細々開発してるだけの立場である自分の方から頑張って他のアドオンのコードをなんとか読み解いて連携のためのハックを考える、という事しかやってこなかったので、向こうの方で解決してもらえたということが嬉しかった。

他のアドオンと衝突しないように心がけたいし、心がけて欲しい - Apr 17, 2009

「次のエントリで書く」なんて予告じみたことを書いてはみたものの、どうも話がまとまらない。もう、思ったことを箇条書きで書くだけにする。

現実的に言って、1つのアドオンであらゆる人のニーズを満たすことは不可能だと思うし、そういう方向での努力はしない方がいいとも思う。何でもかんでも……と際限なく詰め込んでいくと、どこかで破綻すると思う。機能の詰め込みは、ある時点までは効率がいいんだけど、ある時点を超えてしまうと、デメリットの方が大きくなってくる。「Piro拡張化」なんて言われるようになる。

作る側の心理として、どうして機能を増やしたくなるのか。他の人はどうか知らないけど、僕はこんな感じだった。

• デバッグより、新機能を実装する方が楽しい。モチベーションが高まる。
• 大は小を兼ねる。大きいことはよいことだ。みたいな。
  • 「こんな小さな物をたくさん作りました」よりも「こんなデカい物をたった一人で作りました」の方がなんかすごそう。
  • より多くの人のニーズを満たせば、より多くの称賛を得られる。誉められて嬉しい。
• それまでに作った部分を土台や部品として使えるので、新しい別個のアドオンにするのに比べてはるかに楽に「すぐ動く物」ができる。
  • 共有できる部分が多ければ、それだけ「無駄が無い」と言える。同じことをするコードが複数のアドオンにあるのは、無駄なことで、気持ち悪いと感じる。
  • 複数の機能を有機的に連携させて、「100％ぴったり、思い通り」の挙動を実現できる。

そんな感じの理由でどんどん機能を加えていく。ある時点までは、それでうまく回る。応援してくれる人とか感謝してくれる人とか、モチベーションを高めてくれる声も寄せられる。でも、なんかの閾値を超えたところで、あらゆる物事が下り坂に転じる。

• 目が行き届かない所が出てくる。
  • 自分が使う物は目が届くけど、使ってない機能には目が届かない。
  • 自分の環境では問題ないのに他の環境では問題が起こる、というケースが頻発するようになる。
• 機能同士が複雑に絡み合っているので、原因の特定がどんどん困難になる。
• 既にある機能との整合性を常に考えないといけないため、新しい機能を加えにくくなってくる。新しい機能を加えることに物凄くエネルギーを使わないといけなくなる。
• 作り込めば作り込む程、前提とする環境への依存が強くなる。
  • 前提がちょっと変わるともう全然動かなくなる。Firefox 1.5向けに作り込んでいたから、もはやFirefox 2に対応できない。
• 最初の頃は「こんなの今まで無かった！　これがあると大違い！　素晴らしい！」と称賛されていたのに、だんだんそれがなくなってくる。
  • 「定番だよね」「むしろ当たり前だよね」と言われるようになってくる。
    • 使う側から見たら「あって当たり前」という感覚だから、感動なんてしない。最初の時点で「とりあえず入れとけ」みたいな感じで勧められるから、それが無い時の不便さも、それを導入することで起こる変化にも、気がつかない。
    • 本当だったら使わなくてもいいはずの人まで、「なんかみんな使ってるみたいだし、入れとくか」という感じで使うようになる。
    • アドオンは薬のようなもので、導入するのは薬効と副作用のトレードオフ。どうしても必要な薬効があるから副作用を我慢して使う、というのが本来そうあるべき使い方なのに、薬効をそもそも知らないまま流されて服用して、副作用に苦しむことになる。
      • 「バグが多い」「不具合ばっかり」「他のアドオンと衝突しまくる」などのデメリットばかりがとりあげられるようになってくる。
    • 「定番なんだから責任持って作れよ」「こんな事もできないの？　定番なんだからできて当然なんじゃないの？」みたいな、お客様気分の声が増えてくる。やる気を削がれてくる。

そんなわけで、精神的な負荷と時間的なコストがどんどん大きくなっていって、タブブラウザ拡張は破綻した。Firefox 1.5のサポート完全終了と共に、過去の遺物となった。

• かといって、Firefox 2デフォルトの状態で我慢できるわけもなくて。
• でも、タブの複数行表示機能をやめてツリー表示しか使わなくなってしまっていた自分には、今更Tab Mix Plusに乗り換えるというのも考えられなかった。
  • 感情的な理由もあった。後から来て追い抜いていった（と同時に、良い評価もかっさらっていった）相手に自分が依存するのは屈辱だと思った。
  • TMPも「Piro拡張化」の行き着く果てまで来ているように思えた。ここから先は下り坂だと思った。

そういうわけで、過去の自分の失敗を徹底的に反省して、ゼロからやり直すことにした。

• 全部詰め込むのはやめる。1つ1つのアドオンを可能な限り単機能に保つようにする。
  • 多少効率が悪くても、重複する部分があっても、個別のアドオンに分ける。
  • 重複する部分がデカくなるようだったら、ライブラリにする。
    • ライブラリはファイル単位で上書きできるようにする。ファイルの中を見て必要な箇所を切り貼りして……という風なことはミスの元になるから、やらない。
    • 複数の異なるバージョンの同じライブラリが同時に入っていても、問題なく動くようにする。
    • という考えで作ったライブラリをリポジトリにまとめてある。
  • 関係ない機能を含めない。コンセプトが合わない機能は、簡単に実装できそうであったとしても、加えない。
    • これはユーザにもメリットがある。
    • 多機能で「とにかく便利」なんてコンセプトだと、ユーザは入れてみるまで薬効と副作用の比較ができない。入れた後も、どれが薬効でどれが副作用なのか分からない。
    • 単機能なら、薬効と副作用を比較しやすい。「この機能はいらないから、入れない」という判断ができる。「よく分からんけどとりあえず入れてみる」という選択を防ぐ圧力が生じる。
      • 多機能にするよりユーザ数は多分減る。でもそれでいい。薬効が必要なくて副作用しか得られない人にまで、使ってもらいたくない。
• 主要な機能を、他のアドオン（自分が作る物も含めて）から使いやすいように「API」として公開する。
  • といっても、物自体は変わらない。あくまでただのメソッド。ただ、作る時の心構えを変える。
    • 自分だけが使うものだから……と思っていると、メンバ変数とかをがんがん使った、実装するのが楽な、結合が密な設計にしてしまいがち。
    • 結合が密だと、100％全ての情報の流れを理解している人間でなければメソッドを使えない。
    • 半年くらいして自分でもすっかり忘れた頃にもう一度見て、すぐに理解できるか？　理解できなさそうなら、それは駄目な設計。
    • 結合をなるべく疎にする。密な結合にしないといけない時は、せめて、情報が双方向に流れないようにする。一方通行に処理を追いかけるだけで理解できるようにする。
  • インターフェースを公開して、ドキュメントも作る。
    • 既に公開してしまっている物だから、安易に変更できないというプレッシャーがかかる。APIの互換性を維持する力が働く。
  • 機能同士の連携は、必ず公開APIを経由して行う。
    • APIでできないことはしない。
    • 必要なら新しいAPIを考える。やっつけ仕事ではなく、ちゃんとした設計で。
• TBEでやってたような、ガチガチの作り込みはしない。
  • 泥臭くてカッコ悪くても、フレキシブルな対応が可能なやり方を取る。
    • XBLでスッキリ書くより、DOMでゴリゴリ書く。
  • なるべく、Firefox自体が持つ構造を壊さない。
    • 要素構造を自分好みにすっかり作り替えてしまえば、自分は楽になる。でも、ユーザが困る。他のアドオン作者も困る。要素構造を変えると他のアドオンと衝突しやすくなる。
  • XBLの使用はできるだけ避ける。
    • 特に、既存のバインディングの「置き換え」は「最後の手段」「禁じ手」と考える。
    • 「まだバインディングが行われていない部分への追加」だったら、使ってもいい。
    • どうしてもXBLじゃなきゃ実現できない、という部分だけに限って使う。それ以外でXBLを使うのは、極論すれば「珍しい技術を使ってる自分」に酔っぱらってる自己満足な行為でしかない、と考える。
  • メソッドを丸ごと置き換える、という事はできる限り避ける。
    • やるのなら、eval()による部分的な書き換えで対処する。
    • やりたいことの大半は、元のメソッドの最初か最後に処理を追加するだけ。メソッドを丸ごと全部別物に置き換えてしまう必要は本来無い。
    • 見通しは悪くなるけど、他のアドオンとの競合は起こりにくくなる。と思う。
    • これによる開発効率・メンテナンス効率の低下は、個々のアドオンを単機能に・シンプルに保つという前提によって相殺する。
• 他のアドオンでできることはしない。
  • 自分一人で抱え込まない。他の人がやってることをわざわざ自分でやり直そうなんてことはしない。
  • 組み合わせて使うことを積極的に推奨する。自分自身も、他のアドオンと組み合わせて使う。
    • 組み合わせて使って問題が起こりにくい設計にしないといけない、という圧力が自然とかかる。

こういう考えに基づいて作ったのが、マルチプルタブハンドラ、情報化タブ、ツリー型タブ、ソース表示タブという4つのアドオンだ。上に書いたことを完全に守れてるとは言えない部分もあるけど、昔に比べれば遙かにマシになってると思う。

作る側としても、使う側としても、僕は今の方がずっと楽だ。

「多機能に」「1つだけで様々なニーズに応えられるように」という方向に頑張ると、縛りがどんどんきつくなってくる。1つのアドオンだけでできることを増やしていこうとすると、妙な話だけど、他のアドオンに頼れなくなっていく。作り込むほどに、そのアドオンを入れた結果が素のFirefoxとかけ離れてしまうから、他のアドオンとの互換性がどんどん失われていく。だから、1つのアドオンだけでしなきゃいけない事がイモヅル式にどんどん増えてくる。

ユーザの視点から見ると、「多機能なアドオン1つだけの世界で完結した使い勝手を享受する」か、「いろんなアドオンを組み合わせて使う」かの、どっちかを選ばないといけないということでもある。両立はできない。

ここで改めて念を押すけれども、僕は、Tab Mix Plusと上記のタブ系アドオンの組み合わせは推奨していない。一応TMPで動くようにはした、けれども、継続的に追っかけ続けるモチベーションが無い。何故なら、僕はTMPユーザではなく、TMPと組み合わせて壊れるようであっても僕自身は全く困らないから。TMPユーザでない他のアドオンの作者の中には、同じように感じてる人もいるんじゃないかと思う。自分が使ってもいないのに対応を迫られるなんて、厄介な奴だ、目障りな奴だ、みたいな。閑話休題。

「多機能なアドオンで、部分的には、痒い所に手が届くような感覚がある。でも、足りない部分もある。それを補うための他のアドオンと組み合わせて使うことは、残念ながらできない。」「単機能のアドオンをたくさん入れていて、それぞれはそれなりに便利。でも、いまいち連携が取れてなくて、痒い所に手が届かない。」そのどっちかを選ばないといけない。

一人あるいは少数の作者の頑張りだけに期待しなきゃいけない、期待して待ってなきゃいけない。多機能長大路線を歩むという事は、ユーザにそれを強いるという事だと思う。僕はそれが嫌になった。

多分、多機能な物を「作る」だけなら、誰にでもできるんだと思う。時間さえかければ。当時の僕にもうなる程の時間があった（大学生で、レベルもそんなに高くなかったから楽に単位を取れて、その分自由に時間を使えた）から、できてたんだと思う。でも、より大きな問題は「作った」の後にあると思う。メンテナンスし続けられるのか？　他のアドオンと協調させられるのか？　多機能長大路線ではそれは難しいと、僕は思った。

リンクから開かれた新しいタブでも「戻る」を使えるようにするTab Historyがイイ - Dec 03, 2008

Firefoxタブ常用者のための最新エクステンションガイド - SourceForge.JP Magazine で「ツリー型タブを入れてるとTab History が無効になる」と書かれてたので「なに！」と思って入れてみたんだけど今の所特に不具合無く動いてるように見える。一応ソースも見てみたけど、特に衝突する点も無いような……一カ所「もしかして、ここか？」と思う所は無くもないんだけど。そこだけ次版で手を入れておくか……（追記：ツリー型タブ 0.7.2008120401で一応手を入れてみた）

その問題はさておき、Tab Historyは確かに良い。万人にお勧めできると思う。よくある「初心者ユーザがリンクをクリックした時に勝手に新しいウィンドウが開かれて、それが全画面表示になっているせいで、『元のページに戻りたいのに戻るボタンを押しても何も起こらないムキー！！！』となってしまう」という現象、のタブ版を防ぐ物だと言えるだろう。自分はよく、あるタブから子タブを開く→子タブを見ている間に親タブを閉じる→やっぱり親タブをもう一度見たくなる→閉じたタブを開き直す　という操作をやるのだけれども、Tab Historyが入っていれば、子タブしか残っていない状態でも「戻る」ボタンで親タブで見てたページに戻れる。

ていうかソース覗いてみて思ったけど、これ作った人頭いいなー。タブが開かれる時に引数でリファラが指定されていたら現在アクティブなタブから開かれたタブであると見なしてセッションヒストリを引き継ぐ、という判定をしていて、最小限の変更で適切な動作になるようにしてる。まあリファラを偽装する系の他のアドオンと組み合わせた時には問題が起こるかもしれないけど。僕にもこういうピンポイントで問題を解決する力が欲しい。

あとPrint All Tabsにちょっと興味を引かれたので、マルチプルタブハンドラのタブ選択時のメニューに「選択したタブを印刷」を加えるようにしてみてる（Print All Tabsをバックエンドに使うので、Print All Tabsが入っていない場合は使えない機能となる）。

Minefield 3.1b3preの、タブのドラッグ＆ドロップへの対応 - Dec 02, 2008

ツリー型タブとマルチプルタブハンドラで、Firefox 3.1からの「ウィンドウ外にタブをドロップしたら新しいタブを開く」機能に対応した。子タブを持っているタブをウィンドウ外にドロップしたら子孫タブまで含めて新規ウィンドウに分離され、複数のタブを選択してウィンドウ外にドロップしたら選択されたタブすべてが新規ウィンドウに分離される。という感じ。ちょっと前の分割ブラウザの更新もこれに関係してる。

Minefield 3.1b3preでは、ブラウザのタブをドラッグした時はapplication/x-moz-tabbrowser-tabという型のデータがドラッグデータのリストの先頭に加わるようになった。今までは、ドラッグセッションの「ドラッグを開始した要素」をその都度参照していたようだったので、やっとまともな実装になったなーという感じだ。

分割ブラウザやツリー型タブでは、この型のデータも受け入れ可能なように修正した。そうしておかないと、「application/x-moz-tabbrowser-tab型のデータはドロップできないんだな」と判断されて、タブをタブバーや分割された領域にドロップできなくなってしまう。

Minefield 3.1b3preでの「ウィンドウ外へのドロップ」はどのように実装されているのかを調べてみた所、dragendイベント（ドラッグが終了した時に、「ドラッグが開始された要素」で発行されるイベント）のタイミングで、ドロップ操作に失敗した（ドラッグ操作終了時点でポインタの状態が「ここにはドロップできません」のポインタになっている）場合には「ウィンドウ外へドロップされた」と判断して、新しいウィンドウを開きそのタブとドラッグ元のタブを入れ替える、という風にして実現していた。

この時ドラッグ元のウィンドウでは、tabbrowser要素の_replaceTabWithWindow()メソッドにおいて、新規ウィンドウの第1引数にtab要素を渡して開くだけで処理を終えている。そこから先の「ドラッグ元のタブと新しいウィンドウの内容の入れ替え」は、新しく開かれたウィンドウの初期化処理（BrowserStartup()関数）の方でやってる。

なので、ツリー型タブとマルチプルタブハンドラでは、その両方の処理に割り込むようにした。_replaceTabWithWindow()を呼び出している_onDropEnd()メソッドで、_replaceTabWithWindow()メソッドを呼ぶ直前に割り込んで、切り離されようとしているタブの収集結果がそのウィンドウのタブ全部だった場合には操作をキャンセルしている。また、BrowserStartup()の方では、ウィンドウの第1引数がtab要素だった場合はまずツリー型タブとマルチプルタブハンドラに処理を渡して、何も行われなければ（渡されたタブが子タブを持っておらず、選択もされていないならば）Firefox本来の処理（単一タブの切り離し）に入る、という感じにしている。

ドラッグ元のタブ自身の上にドロップした時までウィンドウの切り離しになってしまうなど、Minefield 3.1b3preの当該機能自体がまだまだ作り込みが甘い感じなんだけど、そういう所にまで手を出すと収拾がつかなくなる＆Firefox 3.1正式版までの間に手を入れられたらまた作業のやり直しになるので、そこら辺は基本的に放置してる。ただし複数のタブを同時に閉じようとした時の問題だけは、閉じるのに失敗したタブが永遠に閉じられなくなるなどの致命的な問題を引き起こすので、ツリー型タブの側で対処している（提出したパッチと同じ事をやってる）。

分割ブラウザ、マルチプルタブハンドラの連携の改善 - Oct 19, 2008

Firefox 3.1からの変更への対応に関する技術情報の中に書いたけど、分割ブラウザとマルチプルタブハンドラの連携を強化したり、分割ブラウザ側の「分割された領域」と「タブ」の連携を大幅に強化したりした。

ということをグダグダグダグダ書いてみても大して伝わらんだろうなあと思うので、実際に動いてる所のデモ動画を作ってみた。

<object width="425" height="350"> <param name="movie" value="http://www.youtube.com/v/-rfZNBy0jic"></param> <embed src="http://www.youtube.com/v/-rfZNBy0jic" type="application/x-shockwave-flash" width="425" height="350"></embed> </object>

Firefox 3.1上でなら擬似的な移動でなくホントの移動になるから、ストレスが無いし、書きかけのテキスト等が失われる心配も無いので、今以上にはるかに気軽に使えると思う。作った自分自身、これらの点がネックで今はほとんど使ってないので……

デモ動画自体の作り方もメモしておく。キャプチャはCamStudio、セッティングは「描いてみた」動画の作り方を参考に、ただしフレームレートは高めで。編集はNicoVisualEffectsでやった。CamStudio＋ffdshowでH264でエンコードしたaviが読み込めなくて詰まったけど、Wikiに挙がってたDirectShowプラグインというのをを入れたらちゃんと読み込めた。そんな具合で、初めてなんでちょっと手こずったけど、DebugMode Winkを使って作るのに比べるとタイムライン操作がやりやすいので、今後はデモ動画を作る時はこのやり方でいこうと思う。