Latest topics 近況報告

Information disclosure vulnerability of Tree Style Tab and Multiple Tab Handler - May 29, 2019

日本語版

As already announced at changelogs, an information disclosure vulnerability was found in Tree Style Tab 2.0-3.0.13 and Multiple Tab Handler 2.0-3.0.6.

• The vulnerability was already fixed at TST 3.0.14 and MTH 3.0.7.
• Please be careful if you deactivated auto-update of addons, or using old TST or MTH on old Firefox. I strongly recommend you to update or uninstall them for safety.

Technically detailed description is already published at a GitHub issue. It was a spec bug around APIs for communication with other addons. In short: the API design was not matched to the security model of WebExtensions API itself.

• A WebExtensions based Firefox addon can read privacy data of tabs, only when such a risk was notified on its installation and you intentionally granted that. Title, URL, and "FavIcon" of tabs are such sensitive data.
• TST and MTH are addons providing list-like UI for tabs, so they must require permissions to access such sensitive tab data. You might saw such notification on your initial installation.
• TST and MTH provide API for other addons to notify information of specified tree or multiselected tabs. The data notified via those API were constructed from tabs.Tab objects got via WebExtensions API with their own permissions, and they contained full tab data from both regular and private windows, including title, URL, and FavIcon, without any confirmation. To be honest, I forgot that those properties are not accessible without tabs which is a non-default permission.
• Their API is callable via a general WebExtensions API browser.runtime.sendMessage(), and any addon can call browser.runtime.sendMessage() with no special permission.
• As the result, sensitive tab data were accessible from any other addon with no permission and no warning when TST or MTH was installed.

Currently there is no report about actual such an "attacker" addon. This vulnerability was found by a self-check.

However, it existed for a long time (from initial releases of their versions 2.0 at 2017), and might be known axiomatically with public API documents - attackers might find it out when he read the API spec carefully. If you found any actual attacker example, please tell them me.

I already contacted to community managers of Mozilla, so I will update this announcement if any progress.

Why I did such a terrible mistake? I think there are mainly two reasons.

First, TST and MTH were originally developed as XUL addons.

In old days, all XUL addons had same permissions: they were allowed to access any data on Firefox. Old API of these addons were also designed on the policy same to XUL addons themselves - there was no concept like permissions for each client addon.

On the other hand, there are some known concepts of WebExtensions: isolated namespaces and secure permission model based on declarations. So users just need to be careful about safety for each addon simply. And, there is one more self-evident (but I missed that) fact: my addons TST and MTH may be allowed to read sensitive data, but other API client addon may not.

This means that it was required that updating the concept of my APIs following to the security model of WebExtensions API itself. But regrettably I forgot to do that - I concentrated to migration of their features and missed this point. As the result, TST and MTH were became like a bigmouth: they got sensitive information out of Firefox and blabbed to others carelessly.

Second, I misunderstood the power of the tabs permission.

The permission name tabs looks like required to do anything around tabs, for example getting a list of tabs. So, because APIs of TST and MTH require id of tabs as their parameter, I thought that "client" addons must have the tabs permission and there was no problem to return full tab information.

But that was misunderstanding. Actually, many WebExtensions API around tabs are callable regardless the addon has no tabs permission, and the permission just appends extra sensitive properties to tab objects. I added tabs to required permissions on very early days of my WebExtensions addon development experience and it was left there for a long time, thus I had no chance to correct such a misunderstanding. Possibly I might specify tabs permission for other addons even if it is unnecessary.

Please remind my mistake as a lesson, if you plan to design callable API for other addons. You need to be careful to treat any data got via WebExtensions API as sensitive, as:

• You should understand the exact effect of the permission you specified at permissions in manifest.json. Don't put needless permissions, and keep it mind that you should make effort to minimize the list of permissions anytime.
• You should build response/notification messages for other addons from scratch, especially without recycling of objects got via WebExtensions API with your own permissions.

ツリー型タブとマルチプルタブハンドラに脆弱性がありました - May 29, 2019

English Version

既にTwitter等でお知らせしていますが、ツリー型タブのバージョン2.0～3.0.13とマルチプルタブハンドラのバージョン2.0～3.0.6に脆弱性がありました。

• 問題自体はツリー型タブ 3.0.14以降およびマルチプルタブハンドラ 3.0.7以降で修正済みです。
• 自動更新を停止していたり、古いバージョンのFirefox用に古いTST・MTHを使用していたりすると、脆弱性を突かれる恐れがあります。更新またはアンインストールを強くお勧めします。

詳細な説明はGitHubのissueに日本語でも記載していますが、端的に言うと「他のアドオンと連携するために独自に提供していたAPIの仕様がガバガバだった」という事になります。

• 通常、WebExtensionsベースのアドオンでは明示的に宣言されインストール時に許可された範囲の情報しか取得できない。タブの現在のタイトル、URL、アイコンもそのような情報の一種。
• TSTやMTHは動作上どうしてもタブのタイトルやアイコンを知らなくてはいけないので、それらの権限を要求する旨宣言している。インストール時にもそのあたりの事が警告される。
• TSTやMTHは、他のアドオンの求めに応じてツリーの情報や選択されたタブの情報を返したりプッシュ式に通知したりするためのAPIを提供している。このAPIを介して返される情報は、TSTやMTHが自身の権限に基づいてWebExtensions APIから得たtabs.Tabのオブジェクトに基づいて、それとの互換性を保つようにしていたため、その中に無条件でタブのタイトル、URL、アイコン、およびプライベートウィンドウのタブの情報が含まれていた。これらの情報が、本来は取得するために特別な権限が必要な物であるという事を失念していた。
• このAPIはbrowser.runtime.sendMessage()というWebExtensions APIを使って呼び出す物だが、browser.runtime.sendMessage()の呼び出しには特別な権限は要らない。
• よって、TSTやMTHがインストールされている環境では、どんな権限でインストールされたアドオンからでも、全く無警告に、そういった情報を参照できてしまうという状態だった。

一応、この「脆弱性」を使って悪さをするアドオンとしてこういう物が実際にある、というような報告はまだ受けていません。あくまで、作者が自主的に行った仕様の再チェックで脆弱性が見つかったという事になります。

が、「誰も気付かないような所、仕様の穴を突いたイリーガルな使い方をすると情報を盗み出せる」というような物ではなく、技術情報としてドキュメントも公開しているAPIを堂々と使って、WebExtensionsのアドオンごとの制限を突破して情報を取得できる、しかもその情報自体は実は2017年のバージョン2.0リリースの時から1年半以上もの間ずっと公知だったという、我ながら書いていて情けなくなるお粗末な状況なので、この脆弱性を利用した悪意あるアドオンが既に存在していても、全くおかしくはないと思っています。

ということで、もしそのようなアドオンを見つけた方がいらっしゃいましたら、お手数ですがどうかタレコミをお願いします。

折良く（？）、Mozillaのアドオンコミュニティの担当者の方からおすすめアドオンの件について連絡を頂いたので、ついでにこの件についても相談してみました。何か進展があったらまた告知すると思います。

それにしても、何故こんなにお粗末な事をやらかしてしまったのか。理由はいくつか考えられます。

まず1つは、XULアドオン時代の設計思想を引きずってしまっていたこと。

元々、XULアドオン時代にはFirefoxのアドオンはすべての情報にフルアクセスというのが当たり前でした。なので、TSTやMTHのAPIには、呼び出し元ごとに返す情報に差を付けないといけないという考えが全くありませんでした。聞かれた事はなんでも返していい、何故ならどうせ呼び出し元のアドオンだって、それらにアクセスしようと思えばいくらでもできるんだから。これがXULアドオン時代の考え方でした。

他方、WebExtensionsでは、各アドオンは事前に許可された範囲の情報しかアクセスできないので、ユーザーは各アドオンの権限だけを気にすれば良いという事になっています。この事ばかりが強く印象に残っていたことと、とにかくXUL版から機能を移植するという事にばかり気を取られていたために、アドオン同士の間ですらもアクセスできる情報の範囲に差があるという事が、頭の中からすっかり抜け落ちていたのだと思います。

「アドオン同士の権限に差がある」というWebExtensionsの世界に合わせるには、TSTやMTHのAPIにもその考え方を反映しないといけなかったんですね。自分のアドオンが正当な手順でWebExtensions APIから入手した情報は、相手のアドオンにとっても同様に正当な手順で入手できる情報だ、とは限らないのです。それを忘れて呼び出し元の求めに応じてなんでも返してしまっていたというのは、「内緒にするから教えて」と言って教えてもらった情報を、他人にホイホイ言いふらすようなものです。実に嘆かわしいです。

2つ目の理由は、permissionsで宣言する権限の影響範囲を正しく把握しきっていなかったこと。

tabsという権限の名前からはいかにも、タブに関する事なら何をするのにも、例えばタブの一覧を取得するのにすらも必須であるような印象を受けます。TSTやMTHのAPIを呼ぶには呼び出し側のアドオンがタブのIDを知っている必要があり、タブのIDを知っているなら当然tabsの権限も持っているはず、ならタブのプロパティ全部渡しても問題無いはず（どうせ呼び出し側のアドオンが自分でも同じ情報を取得できるんだから）。というのが、これらのAPIを作った時点での自分の認識だったのだと思います。

しかし実際には、tabs.query()などのWebExtensions APIはtabsの権限無しでも呼ぶ事ができます。tabs/activeTabの権限の有無は、タブの一覧を取得できるかどうかではなく、返されるタブの情報にタイトルやURLなどのセンシティブな情報が含まれるかどうかという点にだけ影響します。TSTやMTHをWebExtensionsで実装するにあたって、まだWebExtensionsの仕様への理解が浅かったかなり初期の時点でtabsの権限を設定したきりだったために、この勘違いがずっと正されないまま今に至ってしまっていたのでしょう。他のアドオンを作る時にも、自分はひょっとしたらtabsの権限が不要なのに要求してしまっているという例があるかもしれません。

今回のことから得られた教訓は、以下のようにまとめることができると思います。

• それぞれの権限が何を可能にするのか、その権限が無いと何ができなくなるのかを、ちゃんと理解しておく。不要な権限は要求しないようにして、常に必要最小限の権限だけをpermissionsには列挙する。
• WebExtensions APIから自分の権限で取得したオブジェクトをそのまま使い回して、他のアドオン向けのメッセージに含めてはいけない。必ず、センシティブでない事が分かっている情報だけをホワイトリスト形式で抽出して、スクラッチでメッセージを組み立てること。

僕のように「他のアドオン向けのAPI」を提供するアドオンを作ろうと思っている方は、どうか僕と同じ過ちを犯さないように、他山の石として下さい……

Firefox 57とかWebExtensions移行後のツリー型タブとかがクソとかゴミとか言われているのを見て思う事 - Dec 07, 2017

Firefox 57がリリースされた前後から、アドオンが使えなくなってクソだとか改悪だとかの感想を目にする機会があって、気分が滅入る事が度々ありました。

自分自身は、これは必要な事だったと思っていますし、絶望は1年ほど前に嫌というほどし尽くして、今はもう「で、どうやって乗り越えるか」というフェーズに気持ちがすっかり移ってしまっているため、それらの後ろ向きなコメントには正直な所「えっまだそんなこと言ってるの……」という感想を抱いています。そんな後ろ向きな事を言っていないでもっと生産的な事をしましょうよ、と思わずにはおれません。

しかし同時に、自分自身も他の分野ではエンドユーザーとして後ろ向きな選択をしている場面は多々あり、同意する部分が無いとも言えません。というか今絶望している人達と同じような事をつい1年から2年ほど前には自分も言っていた訳で、それを思い起こす度に、し尽くして乗り越えたはずの絶望が何度も蘇ってきて、「何故自分がこんな理不尽な思いをせねばならん（かった）のだ？」と憤りの感情が頭をもたげてくるのは否めません。

そういう自分の中での混乱を鎮めるために、エンプティ・チェアを2～3個置いて自分の思う所と結論に至るまでの経緯を各立場から辿り直し、考えを整理してみる事にしました。

続きを表示する ...

マルチプルタブハンドラもWebExtensionsに移行しました - Oct 13, 2017

ツリー型タブのWebExtensions移行の後半作業と並行して進めてたマルチプルタブハンドラのWE移行ですが、こちらも一区切りとしてバージョン2.0をリリースしました。こちらはTSTほどには語る内容が無いので手短に。

マルチプルタブハンドラ（以下、MTH）は元々、「そこにあるFirefoxのタブを雑にドラッグして選択したらメニューが出てきて『で、この選択したタブをどうしたい？』と次のアクションを訊ねてくる」という、操作対象を起点とした操作、本来の意味での「オブジェクト指向」らしい操作というコンセプトに基づくアドオンでした。そのコンセプトを具現化するために、レガシー版ではタブの上でのクリックやドラッグどいった操作をハンドルし、時にFirefox本体の挙動をキャンセルして、「タブをドラッグして選択」という挙動を実現していました。

ところが、WebExtensionsではFirefoxのタブの上での生のイベントをハンドルすることが許されていません。そういうAPIが欲しいという要望は挙がっていましたが、WebExtensions APIのコンセプトに反するということでWONTFIXになっています。よって今後もそういう事ができるようにはならないでしょう。

ただ、WE版TSTは専用のサイドバーを提供していて、その中で発生するイベントを扱う事に関してであれば自分の裁量で好きなようにAPIを提供できます。 なので、WE版MTHは当初は「TSTに完全に依存したアドオン」として開発を始め、TSTにAPIを実装してはMTHでそれを使ってみるという形で両者の開発を並行して進めていたのでした（TSTのAPI整備とその動作検証のための体のいい実験台になってもらったとも言えます）。 その過程で、ツールバーボタンから開いたパネル内であればドラッグ操作でのタブの選択もできなくはないと思い立ったため、TST完全依存のアドオンではなく一応単体でもそれなりに機能するアドオンとしてリリースする方針に切り替えて不足部分を整備し、この度ようやくリリースに至った次第です。

そういう経緯なので、本来意図していたMTHのユーザー体験は、WE版においてはTSTとの併用時においてのみ実現されています。単体のWE版MTHはあくまで仮の姿で、TSTと併用した時にのみ真価が発揮されるとは、なんとも中二病くさい仕様ですね。

ところで、Firefoxにはずいぶん前から（具体的には8年前から）タブを複数選択する機能の実装提案がなされています。 この機能がいつまで経っても実装される様子がないので、渋々MTHを今までメンテナンスしてきた、という部分も実を言うとあるのですが、なんとここに来てそれなりの優先度で解決（実装）に向けて動き始めてきたようです。 もっと早くやってくれていれば、MTHはWE版を開発せずそのまま開発終了にできたかもしれなかったのに……

ともあれ、将来のどこかの時点でMTHがお役御免となるのなら、それに越したことはありません。 その日が来るまでの間は、できる限りメンテナンスを続けていこうと思っています。

以上、MTHのWE版リリースの裏事情でした。

Firefoxアドオンのe10s（マルチプロセス）対応の方針について得られた知見 - Nov 13, 2014

Firefoxのマルチプロセス設計への移行がいよいよ目前に迫っている。

Firefoxにおけるマルチプロセス化のための仕組みそのものはElectrolysis、略してe10sと呼ばれており、Firefox 4の頃から既に入っていて、Firefox Hacks Rebootedでも詳しく解説してたんだけど、ブラウザのUIを動かすプロセスとコンテンツ領域のプロセスを分けるというのはFirefoxではかなりの大ごとだった。一時は「こんなん無理！」っつって計画が凍結されてたほどだったと記憶してる。

e10s移行が困難だった理由は、多分、Firefoxというアプリケーションそのものの設計にあったのだと思う。FirefoxというWebブラウザは、「GeckoというHTML・XMLレンダリングエンジンの上で動作するJavaScript製のローカルWebアプリケーション」といった感じの設計になっている。なのでコンテンツ領域内の操作のためのコードとUI部分の操作のためのコードが非常に似通っていて、シームレスに連携しやすかった、否、「連携しやすすぎた」と言える。あまりにシームレスに連携できたせいで、ブラウザのUIに関わるコードとコンテンツ領域内の操作に関わるコードが渾然一体の密結合になってしまい、それが「UI部分とコンテンツ領域内との間はテキストメッセージだけを非同期に通信しあう」というe10sベースの設計への移行を阻んでいた、という事なのではないか……と僕は思っている。

どういう理由があったのかは知らないけど、最近のバージョンのFirefoxではe10sベースの設計への本格的な以降のための準備が着々と進められている。上記のような密結合だった部分が「UI領域専用」「コンテンツ領域専用」「両方で共通」といった感じに分離されてきているし、同期処理前提だった部分が非同期処理前提に改められている。 セッション保存の仕組み（ページ内のテキストボックスへの入力内容を保存する所とか）、リンクのクリック操作のハンドリング、その他多数の部分が大幅に書き直されている。アドオンから見た時のAPI的な互換性は可能な限り残すようにしてあるようで、その努力の様子が非常に興味深い。

で、アドオン側での対応をどう進めるかなんだけど、実際にいくつかのアドオンをe10s対応に改修してみて、アドオンの性質によって典型的なパターンがあるようだという事が分かった。

1. UI領域内だけで処理が完結するアドオンの場合： 特に何もしなくて良い。browserのcontentWindowやcontentDocumentに一切触れず、コンテンツ領域内からBubblingしてくるイベントも捕捉しないタイプのアドオンは、何も考えなくてもそのままe10sで動く。
2. UI領域内で発生するイベントをトリガーとして、コンテンツ領域内で何らかの処理を行う（処理の結果は利用しない）アドオンの場合： アドオンの実装を、「UI領域からコンテンツ領域へ、処理スタートの指示のメッセージを送る」「コンテンツ領域で指示のメッセージを受け取って、実際の処理を行う」という2段階に分け、実装の一部をコンテンツ領域側に読み込ませるコードの中に移動する必要がある。 マルチプルタブハンドラの場合、「選択したタブをファイルとして保存する」機能について、ページをファイルとして保存する処理をコンテンツ領域側に移動し、UI領域からのメッセージをトリガーとして実行するためのコードを追加した。
3. コンテンツ領域内で発生するイベントをトリガーとして、コンテンツ領域内で何らかの処理を行うアドオンの場合： アドオンの実装を、コンテンツ領域側に読み込ませるコードの中に移動して、そこで処理を完結させるようにする必要がある。
4. コンテンツ領域内で発生するイベントをトリガーとして、UI領域側で何らかの処理を行うアドオンの場合： コンテンツ領域側にコードを読み込ませて、コンテンツ領域内で発生したイベントをUI領域に通知してやる必要がある。 ツリー型タブの場合、タブバーを自動で隠す機能において、コンテンツ領域上でのマウスの移動を検知するために、マウスのボタン操作や移動で発生したイベントをUI領域に通知するコードを追加した。 生のイベントオブジェクトやDOMノードは渡せなくなるので、文字列として渡せる情報だけでもきちんと動くようにする工夫が要る。
5. UI領域内で発生するイベントをトリガーとして、コンテンツ領域内で何か処理を行い、その結果を受けてさらにUI領域側で何らかの処理を行うアドオンの場合： これが一番厄介なパターン。 例えば今までだったらWebページ中のリンクを収集する操作は同期処理で var linkURIs = Array.map(gBrowser.contentDocument.links, function(aLink) { return aLink.href; }); と書けたけれども、こういう事ができなくなる。 UI領域とコンテンツ領域の境界をまたぐ時に非同期処理を挟まないといけないので、処理を「UI領域からコンテンツ領域へ、リンクを収集する指示のメッセージを送る」「コンテンツ領域で指示のメッセージを受け取って、リンクを収集し、UI領域へ結果を報告するメッセージを送る」「UI領域で報告のメッセージを受け取って、次の処理を行う」という3つの段階に分けなくてはならない。 マルチプルタブハンドラの場合、「選択したタブの情報をクリップボードにコピーする」という機能のために、タブ（で開いているページ）の情報からクリップボードにコピーするための文字列を得る処理をコンテンツ領域側に移動した上で、UI領域からコンテンツ領域へ・コンテンツ領域からUI領域への橋渡しを行うためのコードを追加し、前後の処理をPromiseで繋ぐようにした。

上記の5パターンの最初の方の物ほど実装が容易で、後の方の物ほど実装が面倒になる（その上、メッセージの往復を待たないといけないのでオーバーヘッドも大きくなる）。 特に深い意味もなく後の方のパターンで実装していた機能は、どうにかして前の方のパターンで実装できないか検討した方がいい（Firefox本体の設計変更も、おそらくそういう風に進められたのではないかと思う）。 実際に、情報化タブではWebページのサムネイル画像を取得する処理について、元々はUI領域で「サムネイルが必要だ」となったタイミングでその都度同期処理していたのだけれども、まずサムネイル取得の処理はコンテンツ領域に移し、処理が走るタイミングについて、コンテンツ領域側で発生したイベントをトリガーとしてサムネイル画像をUI領域側にpushで送りつけるように改めた。 これは上のリストで言うと、5番目のパターンから4番目のパターンに設計変更した、ということになる。

それでもどうしても5番目のパターンで実装しないといけないケースというのはあって、前後の処理とどうやって繋ぐか（同期処理だった物をどう非同期化するか）というのが問題になる。 自分の場合は、こういう時はPromiseを使うのがいいと思ってる（以前ならJSDeferredを使ってたんだけど、Mozilla Add-onsのレビューが通らないため、最近になってPromise.jsmのES6 Promise互換APIを使うようになった）。 ツリー型タブでも、コンテンツ領域内にプラグイン（Flashなど）で描画されている領域があるかどうかを調べるための処理で、このパターンが残っている。 Promiseを使うコードはUI領域側のブリッジにまとめてあり、こんな感じになってる。

sendAsyncCommand : function CB_sendAsyncCommand(aCommandType, aCommandParams)
{
    var manager = this.mTab.linkedBrowser.messageManager;
    manager.sendAsyncMessage(this.MESSAGE_TYPE, {
        command : aCommandType,
        params  : aCommandParams || {}
    });
},
checkPluginAreaExistence : function CB_checkPluginAreaExistence()
{
    return new Promise((function(aResolve, aReject) {
        var id = Date.now() + '-' + Math.floor(Math.random() * 65000);
        this.sendAsyncCommand(this.COMMAND_REQUEST_PLUGIN_AREA_EXISTENCE, {
            id : id
        });
        return this.checkPluginAreaExistenceResolvers[id] = aResolve;
    }).bind(this));
},
handleMessage : function CB_handleMessage(aMessage)
{
    // dump(JSON.stringify(aMessage.json)+'\n');
    switch (aMessage.json.command)
    {
        ...
        case this.COMMAND_REPORT_PLUGIN_AREA_EXISTENCE:
            var id = aMessage.json.id;
            if (id in this.checkPluginAreaExistenceResolvers) {
                let resolver = this.checkPluginAreaExistenceResolvers[id];
                delete this.checkPluginAreaExistenceResolvers[id];
                resolver(aMessage.json.existence);
            }
            return;
    }
},

• checkPluginAreaExistenceメソッドは、その実行を示すユニークなidを伴ってコンテンツ領域に指示のメッセージを送ると同時に、新たに生成したPromiseのリゾルバ関数を、idと対応付けて保持する。メソッドの戻り値はPromiseとする。
• コンテンツ領域側では、指示のメッセージを受け取って処理を行い、結果のメッセージをid付きでUI領域に送り返す。
• 送り返されてきたメッセージをUI領域側で捕捉したら、idに基づいて、保持していたリゾルバ関数の中から対応する物を見付け、送り返されてきたメッセージに含まれていた情報を渡す形で実行する。

という風にする事で、checkPluginAreaExistenceメソッドをthenableなメソッドとして他の処理の中に無理なく組み込める（次のコールバックには、コンテンツ領域側での処理で得られた結果が渡る）ようになってる。 UI領域→コンテンツ領域→UI領域 と境界を2回以上またぐ処理を実装する時は、多少の差異はあれどだいたいこんな感じになるんじゃないだろうか。

必要かどうかで言うと、このパターンでPromiseは必須ではなくて、Promiseのリゾルバ関数を保持・実行する代わりに、単にcheckPluginAreaExistenceメソッドでコールバック関数を受け取って、それを保持・実行するようにしてもいいんだけど。 非同期の処理同士を何度も書き連ねる時のコールバック地獄は見たくない（今はそういう連携をする必要がないとしても、今後いつ必要になるとも限らない）ので、僕は自分で書く非同期処理は、インターフェースとしては基本的にPromiseを使う方向で統一するように考えてる。

How can I drag tabs with Multiple Tab Handler? / マルチプルタブハンドラがある時はどうやればタブをドラッグできるの？ - Jun 03, 2014

Q

When the Multiple Tab Handler addon is installed, I cannot drag a tab to move it. Even if I start dragging on a tab, mouseover-ed tabs are selected (highlighted) instead of moving the dragged one tab.

マルチプルタブハンドラがインストールされているとタブをドラッグで移動できません。タブをドラッグしようとしても、そのタブが移動する代わりに、ポインタが上に載ったタブが選択（ハイライト表示）されるだけという結果になってしまいます。

A

The addon provides ability to select multiple tabs and do some actions for them. Long-press of your left mouse button on a tab starts the selection, moving mouse cursor selects mouseover-ed tabs, and releasing the button shows the menu for selected tabs.

On the other hand, if you move your mouse immediately after you press the left mouse button on a tab, then the tab is just dragged and moved as you expected. Remember, long-press selects tabs but short-press starts dragging of the tab. To change the threshold, see the configuration dialog of the Multiple Tab Handler.

By the way, you can select tabs without dragging. When you do ctrl-left-click on a tab, it toggles the selection state of the tab. Shift-left-click on a tab selects tabs between the clicked tab and the current tab. This behaviour is same to the one of Microsoft Excel, Windows Explorer, and others. After that, you can open the menu for selected tabs with right-click on a selected tab. If you do short-press of the left mouse button on a selected tab and start dragging immediately, then selected tabs are dragged and moved together.

このアドオンは、選択された複数のタブにまとめて同じ操作を行う機能を提供します。タブの上でマウスの左ボタンを長押しするとタブの選択が始まり、マウスカーソルと動かすとカーソルが上に載ったタブが選択され、ボタンを放すと選択されたタブのためのメニューが開かれます。

他方で、タブの上でマウスの左ボタンを押下してすぐにマウスを動かすと、タブの選択ではなく、通常通りのタブのドラッグ（移動）操作となります。憶えておいてください、長押しすると選択が始まって、長押ししないですぐにマウスを動かすとタブのドラッグです。長押しと判定する時間の閾値はマルチプルタブハンドラの設定ダイアログで変更できます。

ちなみに、長押しからのドラッグ以外の方法でもタブは選択できます。タブの上でCtrl-左クリックすると、タブの選択状態が反転されます。また、Shift-左クリックすると、クリックされたタブと現在のタブまでの間がまとめて選択されます。これはMicrosoft ExcelやWindows Explorerなどの他のアプリケーションと同じ挙動です。そうしてタブを選択した後に、選択されたタブの上でマウスの右ボタンを押すと、選択されたタブのための操作のメニューが表示されます。選択済みのタブの上でマウスの左ボタンを押下してすぐにマウスを動かすと、選択されたタブをまとめてドラッグ（移動）する事もできます。

tabFx2Compatible.xul、tabFx2Compatible.css、tabFx2Compatible.xmlを使わないようにした - Feb 09, 2012

ツリー型タブ、情報化タブの今日付でのリリース分から、tabFx2Compatibleという自作のライブラリ（？）を使わないようにした。当初はマルチプルタブハンドラでも使ってたけど、ツリー型タブ・情報化タブに先駆けて一足先に使わないようにしていた。今回残りの2つでも利用をやめたことで、TBEやり直し組のアドオンからはこのライブラリが全く姿を消したことになる。作ったのが2008年の2月からだから、丸4年くらいは使ってたのか。

このライブラリは元々、Firefox 3での仕様変更に追従するために仕方なく作った物だった。

Firefox 2ではタブの中に任意の要素（サムネイル描画用のcanvasだったりカウンタ表示用のlabelだったり）をXBLのコンテナ要素を使って動的に追加できていた。しかしFirefox 3になる時、具体的には2007年の12月頃に、高速化のためにそういう冗長性を排除する変更が行われてしまって、JavaScriptで動的にタブの内容を追加するということが原理上不可能になってしまった。

正確には、方法はあった。Firefox本体がタブに適用していたXBLによるバインディングを独自のバインディングで置き換えて、それを使ってタブの内容を変更するというやり方だ。しかし、XBLのバインディングは同時に1個だけしか適用できないという制限がある。複数のアドオンが同じ事をやろうとしたら、結局どれか1つのアドオンしかまともに動かないという事になってしまう。他の人の作る物との互換性という話に限らず、リッチでファットなAll-in-One型のアドオンであったTBEを捨てて各機能ごとに個別のアドオンに開発し直す道を選んでいた僕にとっては、自分の手がける物同士の互換性を維持するためにも、これは致命的な問題だった。

前述のライブラリは、特定のアドオンのために特化したバインディングを適用するのではなく、Firefox 2時代の「ある程度好きなようにタブの内容を増やせる余地がある」、冗長性を持った汎用的なバインディング定義を、Firefox 3向けに復活させるという物だった。

風向きが変わったのは2010年9月の事だった。Firefox 3.7のモックアップで示された視覚的なデザインを実現するために、タブのバインディングに再び冗長性が付与された。メジャーバージョンとしては、この変更はFirefox 4から反映されている。僕はこの仕様変更をうけてtabFx2Compatibleを改修し、Firefox 4以降のタブのバインディングの構造と、Firefox 2以前のタブのバインディングの構造の、両方を併せ持つ状態に変更した。

という経緯を見ると分かるかもだけど、このtabFx2Compatibleというライブラリは本質的に、Firefox 3.0から3.6までの間のバージョンに対応するためには欠かすことができなかった。ツリー型タブ等のアドオンの対応バージョン範囲の下限がこの範囲に重なっている間は、このライブラリは絶対に使う必要があったので、いくらTMPやVimperator等とバインディングの衝突の危険性があったとしても、構成ファイル群から外すことができなかった。

今回、Firefox 10のESR（延長サポート版）がリリースされたことにより正式にFirefox 3.6の死期が確定したので、サポート終了を待たずにFirefox 3.6のサポートを打ち切って、それと同時にtabFx2Compatibleも廃止することにした。レガシーなFirefox 2由来のDOMツリー構造を前提にして書かれたスクリプトやスタイルシート等を、全面的にFirefox 4以降の既定のDOMツリー構造に合わせて変更する作業は、それなりの手間を要したけれども、これでカビの生えた過去から決別できるのなら安い物だと思った。

選択肢の1つとして、tabFx2Compatibleを今後も使い続ける（Firefoxのタブのバインディングの構造が変わったら、その度にtabFx2Compatibleを更新していく）というやり方もあった。今この瞬間にかける労力を最小化する事を選ぶのなら、そういう選択もあり得たと思う。でも、tabFx2Compatibleは元々Firefox 3から3.6までの暗黒期を乗り越えるためだけに用意された物だったのだから、用済みになったのなら、思い切って捨てた方が今後のためになると思った。

こういう切り替えをできる時にやっておかないと、またTBEみたいな事になってしまう恐れがある。TBEでは、タブの移動等といった基本的な機能すらFirefox本体に備わっていなかった頃から開発していたため、TBE自身で独自の「タブを移動する」などのAPIを実装していた。そういう古いオレオレAPIから、Firefox 1.5くらいから新しくFirefox本体に備わったTabMoveとかのDOMイベントベースでのやり方にスイッチする事の手間を惜しんで、「とりあえず今動いてるから」と独自のオレオレAPIを維持することに固執してしまったがために、TBEはFirefox 1.5とともに時代に取り残され死んでしまった。そんな愚はもう繰り返してはいけない。

それにつけても、あの辺（Firefoxのタブまわり）の開発をやってる人達の意向に振り回されっぱなしだった4年間だったなー……と思うと、なんか感慨深い。

マルチプルタブハンドラで、タブの選択で一部のタブがスキップされないようになった - 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」の直訳で「すべて閉じる」とかになってたのを「閉じる」のようにまず動詞が先に来るように直した。こうしておかないと、メニューに項目がずらっと並んだ時にぱっと見で判別できなくて困るという事が多かったので。

ツリー型タブとマルチプルタブハンドラのイベント周りのAPIをちょっと変えた - Jan 11, 2011

Tree Style TabとMultiple Tab Handlerを更新した。

今回のアップデートでも例によってMinefield対応のための修正をちょっとずつ入れてるんだけど、その中で1つ、なかなか気付いてなくてハマってた所があった。それはカスタムイベントを使ってた部分。

DOM2 Eventsではこんな風にして任意のDOMイベントを発行できる。

var event = document.createEvent('Events');
event.initEvent('MyCustomEvent', true, false);
event.status = 'current status';
event.tab = tab;
gBrowser.dispatchEvent(event);

受け取る側はこれをaddEventListener()で登録したリスナで拾うようにすれば、各々のモジュールの結合度合いを弱められる。なので僕は自分のアドオンでも積極的にこれを使ってる。

が、これがMinefieldでは使えなくなってた。

多分Compartment（JavaScriptのメモリ空間をスクリプトのオリジンだったかウィンドウだったかごとに分ける機能）が入ったからだと思うんだけど、Chrome URLのスクリプトで上記の例のように追加した任意のプロパティを、JavaScriptコードモジュール側のイベントリスナで参照できなくなってた。上記の例だと、捕捉したイベントのevent.tabがundefinedになってしまってて、こういうやり方で情報を引き渡してた部分がエラーになってしまってた。wrappedJSObjectもundefinedなので、生のオブジェクトを辿る事もできなかった。

MDCにある任意のカスタムイベントを実装する方法の詳しい説明によると、XPIDLでインターフェースを定義してC++で実装を書いてという事をやれば、今までと完全に同じAPIで任意のイベントを発行できるようなんだけど、それはちょっと重たすぎてやる気になれない。

なので次善の策として、汎用のデータを受け渡すためのイベント型があればそれを使おうと思って検索したら、Firefox 3以降ではDataContainerEventとかMessageEventとかの型のイベントが利用可能になってたという事を知った（今更）。

渡すデータがJSON文字列化できる物なら、WebSocketで定義されてるMessageEventがいいっぽい。

var event = document.createEvent('MessageEvent');
event.initMessageEvent('MyCustomEvent', true, false,
  JSON.stringify({ status : 'current status',
                   tab : tab.getAttribute('id') }),
  '', '', null);
gBrowser.dispatchEvent(event);

受け取った側はJSON.parse(event.data)でデータを復元できる。

DOM要素とかも渡したいなら、nsIVariant型でデータを受け渡せるDataContainerEventを使うしか無さげ。

var event = document.createEvent('DataContainerEvent');
event.initEvent('MyCustomEvent', true, false);
event.setData('status', 'current status');
event.setData('tab', tab);
gBrowser.dispatchEvent(event);

受け取った側はevent.getData('tab')のようにしてデータを取得できる。

ということで、プロパティアクセスにしてた所は全部DataContainerEventのやり方を使うように直した。ただ、後方互換性のためにプロパティアクセスでも情報はセットしてあって、同じCompartmentのスクリプトからなら多分今まで通りのやり方でも情報を受け取れると思う。

あと、DataContainerEventの存在を知る前に、MDCのドキュメントに書いてあった「イベント名がnsDOMで始まってない物は任意の情報は受け渡せないよ」という部分を読んでイベント名を「nsDOMTreeStyleTab...」という感じに変えていて、実際これでちゃんと動くようになった部分もあったんだけど、結局DataContainerEventにするようにしたからこれは結果的には余計だったかもしれない……

タブをドメインごとにソートする機能が欲しい / Auto-sorting of tabs by domain (or other conditions). - Dec 08, 2010

Q

Could you add the option to Tree Style Tab or Multiple Tab Handler, to keep tabs with same domain/host in alphabetical order. In other words auto grouping by domain or host.

ツリー型タブまたはマルチプルタブハンドラに対して、同じドメインまたは同じホストのタブをアルファベット順で表示させる、というオプションを付けてもらえませんか？　言い換えるとつまり、ドメイン名やホスト名によるタブのグルーピングということです。

A

Group/Sort Tabs provides the feature, so try it please. However it doesn't work with my Tree Style Tab.

I have no plan to do it on the Tree Style Tab, because I believe that tree of tabs is a "visualized history of web browsing". In the concept, "tree of tabs" and "auto-sorting by domain" mix is like oil and water. (By the way Tab Kit provides both features, so it possibly become your favorite instead of TST.)

Group/Sort Tabsというアドオンがその機能を持っているので、試してみてください。しかし、このアドオンはツリー型タブとは併用できないようです。

私はタブのツリーを「ブラウズ履歴を視覚化した物」と考えていますので、ツリー型タブにこの機能を付ける予定はありません。このコンセプトにおいて「タブのツリー」と「ドメインによる自動的な並べ替え」は相性が悪いです。（ちなみにTab Kitはその両方の機能を提供します。ツリー型タブよりもそちらの方があなたにとって気に入るかもしれません。）