Latest topics 近況報告

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正式版までの間に手を入れられたらまた作業のやり直しになるので、そこら辺は基本的に放置してる。ただし複数のタブを同時に閉じようとした時の問題だけは、閉じるのに失敗したタブが永遠に閉じられなくなるなどの致命的な問題を引き起こすので、ツリー型タブの側で対処している（提出したパッチと同じ事をやってる）。

ツリー型タブ 0.7.2008110801で最大化の問題を修正したよ - Nov 08, 2008

表題の通り。最大化状態でFirefoxを終了して次にFirefoxを起動した時に、最大化が勝手に解除されてしまう問題。ブラウズ領域の描画内用が変になることがある問題というのが発生してて、ウィンドウをリサイズしたら直るようだったので1ピクセルだけウィンドウの大きさを変えてまた元に戻すというコードを入れてみてたんだけど、最大化状態でやると最大化が解除されてしまうということに気付かないままリリースしてしまってました。

みんな最大化って結構使ってるんですね……ということを、このバグの報告が大量に来たことで実感した次第です。

ウィンドウ間でのタブの移動、というか、フレームの内容の入れ換え - Oct 19, 2008

Firefox 3.1からは、ウィンドウをまたいでタブを移動できるようになる。アドオンの作者はこれに合わせて修正を行わないといけない場合がある。

また、この機能を実現するために新しく用意された「表示されている2つのフレームの内容を破壊せずに入れ換える」APIは、他の目的でも利用することができる。

続きを表示する ...

タブ系拡張機能 - Oct 16, 2008

そんなわけで（？）、TBE3に含まれる4つともアップデートした。

情報化タブの機能として、Firefox 3.1向けに、最後のタブのクローズボックスを強制的に表示させるオプションを加えた。本体の方でまた隠し設定がどうとか色々変わりそうな気もするけど、とりあえず現時点での仕様に合わせておく。不要になったら機能自体削除の可能性もある。

ソース表示タブは、機能は変わってないんだけど、動的に書き換えてるメソッド類がMinefieldでだいぶ変わってるようだったので、その修正が主。

マルチプルタブハンドラは、ツリー型タブの修正で書いたのと同じ要領でMenu Editorとの競合を解消したり、ツリー型タブと組み合わせた時の地味なトラブルを直したり、といった程度。

ツリー型タブ - Oct 15, 2008

ツリー型タブ 0.7.2008101501。前の版から4ヶ月も経ってた。使ってて見つけたバグはちまちま直してたんだけど他のユーザの人から英語で寄せられるバグ報告を放置放置でほったらかしてる間にまたずいぶん溜まってしまったのでちょっと頑張って処理してみた。FireGesturesの仕様変更への追従なんてもう何ヶ月も前の変更だから、もう意味が無くなってるかもしれないけど……まあ誰かに言われたら直そう（ぉぃ）。

Menu Editでタブのコンテキストメニューの項目が無限増殖する問題は、多分、分割ブラウザとの組み合わせを見越して各tabbrowser要素ごとにポップアップメニューの項目に一意なid文字列を生成するようにしていたせいだと思う。<tabbrowser id="content"/>なやつだけ特別に固定のidにするようにして、手元で試した限りでは無限増殖の問題は起こってない。マルチプルタブハンドラでも同じ問題が起こってるはずなので（報告すでに受けてたかも。あまりに多すぎて埋もれてしまってる可能性大。）、これは次のリリースで同じ修正を入れます。

Tab Mix Plusとの組み合わせで色々問題が起こってるという報告を受けてるけど、設定項目が多すぎてどの組み合わせで問題が起こるのか分からないのでお手上げです。とりあえず簡単に手元で試して再現しなかった物は放置。

Firefox 3での変更点（重箱の隅を突く的な） - May 26, 2008

アナウンスに含まれてるかどうか知らないけどものっそ細かい所での変更点で僕が詰まった所。

• Windowsにおいて、ドラッグ中でもタイマーが機能するようになった
• nsIDocShellTreeItemのchildOffsetプロパティがなくなった

まず一つめ。Firefox 2まででは、何かオブジェクトをドラッグしてる間はsetTimeoutやsetIntervalで設定したタイマーが発火しないという問題があった（ドラッグ＆ドロップ中のタイマーを擬似的に再現する）。これが、いつの時点からかFirefox 3ではWindowsでも普通にタイマーが動作するようになってた。セカンドサーチやツリー型タブで「ドラッグ中に検索バー（タブ）の上でしばらく待つと〜」系の動作がうまく機能しなくなっていたのは、これが原因。Firefox 3以降ではWindows環境でも普通にタイマーを使うようにコードを書き換えたらうまく動くようになった。

二つめ。 個々のフレームに対応するnsIDocShellのオブジェクトを取得するなどで触れたnsIDocShellTreeItemインターフェースについて、Firefox 3ではchildOffsetプロパティがなくなってしまった。XUL/MigemoでFirefox 3においてフレームを跨いだ検索ができなくなっていたのはこれが原因（今フォーカスしてるフレームの次のフレーム、を取得するためにこのプロパティを使っていた）。かっこ悪いけど、親フレームの子フレームリストを取ってきてループ回してchildOffsetに相当する値を算出するようにしたらうまく動くようになった。

なんで今更になってこんな所（後者）をいじったんだか……

タブバーを自動で隠す時の透過の様子のデモ - Mar 11, 2008

ツリー型タブでタブバーを自動で隠す設定の時に、うそっこ透過タブバーで下の物が見えるようにした、と書いたけど、その様子のデモを作ってみた。

<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" width="300" height="283" codebase="http://active.macromedia.com/flash5/cabs/swflash.cab#version=5,0,0,0"> <param name="movie" value="/xul/_video/treestyletab_autohide.swf"></param> <param name="roop" value="false"></param> <param name="quality" value="low"></param> <embed src="/xul/_video/treestyletab_autohide.swf" width="300" height="283" quality="low" loop="false" type="application/x-shockwave-flash" pluginspage="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash"> </embed> </object>

こうして見てみるとスタック型タブとあんま変わらんように見えるな……

そういや昨日これのためのコード書いてたら、Minefieldでタブバーの幅が300ピクセル以下にならなくて、おっかしーなーと思って色々詳しく調べてみたら、HTML Canvasの幅を0にしようとすると問答無用で300ピクセル幅（canvasの初期状態の幅）になってしまうようだった。さらに検証してみたらFirefox 2ではその逆に高さを0にできないという現象も……Bugzillaを検索してみてもクエリが「canvas width」だとやたらたくさん引っかかって同じバグがすでにあるかどうか分からなかったので、とりあえずバグを立ててみた。ガイシュツだったらすんません。ちなみに幅も高さも、最小値は1ピクセルまでだったらちゃんと指定通りに動くようです。というバッドノウハウ。

追記。しばらく使ってみたら、タブの下の何もないスペースを、タブバーがあることを忘れてうっかりクリックしてしまうということが頻発したので、タブバー部分はそうと分かるように色を変えるようにした。

ウィンドウ全体を覆い隠してゴニョゴニョするためのライブラリを作った - Mar 10, 2008

ツリー型タブでタブバーの表示・非表示を切り替える時の画面のちらつきがUZEEEEEEEEEE！！というのは前々から把握してたんだけど、一時的に画面描画を止めるとかそういうのはJavaScriptのレイヤからは手が出せないっぽいので放置してた。AutoHideではC++あたりでXPCOMコンポーネントを作ってどうにかしてるようだけど、そんなん僕には作れないし。

でもよく考えたらHTML Canvas使って解決できるんじゃね？　と思って、そういう物を作ってライブラリ化してみた。fullScreenCanvas.show()を呼ぶと、今のウィンドウの表示内容のスクリーンショットを貼り付けたような状態のCanvasがウィンドウ内の要素の最前面に表示されます。画面がチラつくような処理をその下でやって、終わったらfullScreenCanvas.hide()でCanvasを消す、という風にすると、ユーザにイヤンな思いをさせないでいろんな事ができるかも知れない。ブラウズ領域のスクロールバーの部分が描画されないのはどうにもならなかった。

以下、工夫した所。

• Minefield 3.0b5preではposition:fixedにしてもCanvasがブラウズ領域の描画内用の下に潜り込んでしまう。フレーム（iframe, browser, tabbrowser）があるとそっちの方が上に描画されてしまうようだ。というわけでGecko 1.9の時だけbrowser要素を動的に生成してその中にcanvasを置くようにした。
• Firefox 2でも、position:fixedを指定したcanvasがブラウズ領域の下に潜り込んでしまう。これは毎回positionプロパティの値を指定し直してやる事でうまく動くようになった。
• drawWindowは、フレームを含むwindowを指定した場合はサブフレームの中身まで描画するけど、Chrome Windowを指定した場合はbrowser要素やtabbrowser要素で形成されるサブフレームの中身が描画されない。しょうがないので、browser要素やtabbrowser要素を全部収集してループで一つずつ描画するようにした。

XULとCSSのポジショニングの組み合わせは、Gecko 1.9でもバッドノウハウの塊ですね。

Firefox 3のタブにFirefox 2と同じプレースホルダーを復元するライブラリと併せて、MITライセンスでの公開とします。

追記。canvasついでに（意味不明）、タブバーの後ろにcanvasを置いてうそっこ透過タブバーを実現してみた（描画内容が微妙にズレることがあるのは勘弁してください）。これで、ページの閲覧を邪魔されずにタブバーを使えるようになるだろうか？

ツリー型タブの最近 - Feb 28, 2008

ここ最近のツリー型タブの状況まとめ。

先週末くらいから現実逃避度合いが加速して、それがそのまま頻繁なバージョンアップに繋がっています。この1週間くらいでやったことのうち大きなトピックは以下のような感じか。

• 公開申請が通って、晴れてサンドボックスから出た。
• Firefox 3 Beta3（正確にはb4pre）対応。
• タブバーの固定、表示位置変更をコンテキストメニューから可能にした。
• マルチプルタブハンドラでの複数タブドラッグに対応。
• Highlander、PermaTabs、ColorfulTabs、Super DragAndGo、Drag de Goとの競合の解消・連携を強化。

他、細々とした改善が多数。だいたいAMOの配布ページのディスカッションに寄せられてた障害報告や要望への対応が多い。

以前TBEをやってた頃は、あまりに規模がでかかったこともあって、とてもじゃないけど他の拡張機能のために配慮するなんて事はできなかった。その点ツリー型タブとかの最近作った物は、なるべく機能を絞り込むように・見通しがよくなるように気をつけている（つもり）ので、あの頃よりもずっと楽にコードを書けてると思う。具体的に名前が挙がったアドオンについて、わりと片っ端から対応用のコードを書いていけてるのも、そういう事情があってこそだ。

しかしいくらサンドボックスから出られたからとはいえやたらたくさんコメントが付いて、正直追いかけるのだけで大変だ。何でだ？と思ってたら、数日前にlifehackerで紹介されてた。コメント欄を見てみると、おおむね好評なようで嬉しい。Firefoxのユーザ全体のうちこの拡張機能を使ってくれてる人の割合は物凄く小さいものだとは思うけど、英語圏はなにぶん人の数が桁違いに多い。英語でリリースしておくと日本語だけでリリースするより多くの人に誉めて貰える&喜んで貰えるので、僕のような構ってちゃんで誉めてもらえないとロクに動けない人間にとっては、その点では都合がいいと言えるかもしれない。

マルチプルタブハンドラで複数タブをまとめてドラッグ&ドロップできるようにしたよ - Feb 24, 2008

表題の通り。Multiple Tab Handlerではタブを選択して操作する機能があるけど、選択後のタブをドラッグ&ドロップしたら全部一緒に移動するようにしてみた。

というのはわりとすぐにできたんだけど、ツリー型タブとの組み合わせが少し大変だった。ツリー型タブがある状態のタブの移動は、単にタブの位置を変えるだけじゃなく、ツリー構造の変更も伴うから。故にツリー型タブではタブのドロップ時の処理をほとんど丸ごと置き換えるようにしていて、そっちの方でMultiple Tab HandlerのAPIを使って対応する（つまりMultiple Tab Handlerはツリー型タブがあるときは、タブのドロップ時は特に何もしない）ようにした。

あと、Firefox 3ではCtrl-ドラッグでタブを複製できるようになってるんだけど、ツリー型タブをこれに対応させるのにも手間取った。というか、今まで適当な処理でそれなりに動いてた部分について潜在していたバグが一気に表面化したという感じ。丸1日くらい使って地道に直した。

ツリー化された複数タブの選択→ドラッグ&ドロップの挙動については、例によってAdobe Illustratorのレイヤ/オブジェクトツリーの挙動を参考にしてる。

以下は未実装の項目。

• Firefox 3ではウィンドウをまたいでタブをドラッグすると「タブの移動」扱いになるけど、ツリー型タブはまだこれに対応していない。→Tree Style Tab 0.5.2008022402で対応
• Ctrl-ドラッグでのタブの複製、ウィンドウをまたいだドラッグ&ドロップによるタブの移動について、Multiple Tab Handlerはまだ対応していない（ツリー型タブの方にかまけててすっかり忘れてた）。→Multiple Tab Handler 0.2.2008022402で対応
• タブのドロップ先がタブバー以外の場合はタブで開いてるページのURIが渡されるんだけど、これも選択されたタブ全部のURIを渡すようにした方がいい？　受け入れ側が複数URIのドロップを想定していない場合は動作がおかしくなる気がする。ああでもHTMLとかプレーンテキストとか、他のアプリケーションやテキスト入力欄に対してのみ渡されるflavourなら問題ないか？