Home > Latest topics

Latest topics 近況報告

たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。

萌えるふぉくす子さんだば子本制作プロジェクトの動向はもえじら組ブログで。

宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能! シス管系女子って何!? - 「シス管系女子」特設サイト

Page 4/243: « 1 2 3 4 5 6 7 8 »

新しいタブとかウィンドウとかで「戻る」を押しても戻れねえよムキーッとなる問題を解消するアドオン「親のタブに戻る(Back to Owner Tab)」をリリースしたよ - Jan 07, 2011

Back to Owner Tabというアドオンを作ってみた。

例えば初心者ユーザにはこういう事がありがちだろう。

  • ブラウザのウィンドウを常に最大化して使っている。
  • タブとかウィンドウとかよく分かってない。「戻る」ボタンを押せば1つ前のページに戻れる、という事は(教わったので)知っている。
  • リンクをクリックした結果新しいページが表示されたとして、それがただのページ遷移なのか、新しいタブで開かれたのか、新しいウィンドウで開かれたのか、違いがよく分かってない。
  • 新しいウィンドウで開かれたページを見終わって「元のページに戻ろう」と思って「戻る」ボタンをクリックするが、ボタンをクリックしても何も起こらない。

こういう場面で、「戻る」をクリックしたらとにかく元のタブなりウィンドウなりに戻るようにするのが、このアドオンだ。

だいたい、ウィンドウを最大化してたりタブを表示しないようにしてたりすると、「戻る」で戻れるのかそうでないのかすぐには分からないから、初心者でなくてもこういう物には意味があると思う。

Firefox 3.5以降では browser.tabs.selectOwnerOnClose が true で且つそのタブが「新しいフォアグラウンドのタブ」として開かれた時にだけ「このタブの親はこのタブですよ」という情報が保持される。また、JavaScriptではwindow.openerでオープン元のウィンドウを辿ることができる。このアドオンは、これらの情報を手がかりにして「親のタブ」を検索するようになってる(ツリー型タブがあるならツリーの構造から親のタブを検出する)。

確かタブブラウザ拡張にもこういう機能を含めてた気がするんだけど、それらを単機能の拡張機能として再実装した時に取りこぼしてた。その後、ツリー型タブにこの機能を含めてくれという要望が何回か来てたんだけど、今だったら browser.tabs.selectOwnerOnClose があるから別にツリー型タブに依存した機能にしなくてもいいよなーと思ったので、こうして今回新たに1つのアドオンとして作ってみたというわけ。

Add-on SDKは使ってないけどBootstrapped Extensionsの形にしてあるので、Minefieldでは再起動無しでインストールできる。昨年の発表では「Bootstrapped Extensionsでは『戻る』ボタンの挙動をオーバーライドするみたいな事はできない」と言ったけど、やってみたらできてしまった。あと、そのために使った方法がFirefox 3.6では動作しなくてちょっと悩んだんだけど、Firefox 3.6ではそもそも絶対に再起動が必要だから「変化を可逆的にする」事にこだわらなくてもいいので、そこは横着してダーティなやり方を使ってる。

なんとなく既出のような気もしたけど、「back owner」とかその辺の単語で検索してもそういう物を見つけられなかったので、じゃあ作るか……と思って作ってみた。既出だったら恥ずかしい。

ちなみに、似たような目的のアドオンでTab Historyという物もある。こちらは「新しいタブを開く時に、元のタブの『戻る』『進む』の履歴を引き継ぐようにする」というアプローチを取っている。僕もTab Historyを使ってたんだけど、せっかく作ったので、しばらくはBack to Owner Tabを使って様子を見てみようと思ってる。

ツリー型タブがCSSの!importantを使いすぎているせいで他のアドオンと衝突する(Tree Style Tab conflicts Tab Utilities, ColorfulTabs, and other tab-related addons because it uses too many "!important" rule in its CSS.) - Dec 18, 2010

Q

With BOTH Tree Style Tab AND Tab Utilities enabled at the same time, the ColorfulTabs extension makes no difference - no tabs get colored. I have reported this to the author of Tab Utilities since it has worked properly in all previous versions of Tab Utilities. But here's his answer:

TU hacks the ColorfulTabs code to reduce its use of "!important", but Tree Style Tab still uses "!important" for tab background-color. I may revert TU's changes, but IMO it's Tree Style Tab who behaves improperly. It uses too many unnecessary "!important" modifiers in CSS rules, which also leads to the conflict with TU for the pinned tabs' position.

Can you fix this please?

ツリー型タブTab Utilitiesが同時に有効になっている時、ColorfulTabsは何の変化ももたらしません──つまり、タブに色が付きません。Tab Utilitesの以前のバージョンは正しく動いていたため、私はこの件をTab Utilitiesの作者に連絡しました。しかし彼はこう言っています:

Tab Utilitiesは「!important」の使用を減らすようにColorfulTabsのコードに手を加えていますが、ツリー型タブはまだ多くの「!important」指定をタブの背景色に指定しています。私はTab Utilitiesに加えた変更を取り消すかもしれませんが、しかし私の考えでは、ツリー型タブのやり方の方が間違っています。ツリー型タブはあまりに多くの不必要な「!important」指定をCSSの中で使っており、これはTab Utilitiesの「ピン留めされたタブ」の配置を壊す原因にもなっています。

この件について修正してもらえませんか?

A

Those "!important" are surely required, because appearance of tabs can be modified by third-parties' theme. For example, if a theme defines black background with white text, then partially applied styles from TST possibly make lighter background with white text -- yes, it is very hard to be read. To avoid these cases, I decided to use "!important" rules. Actually I got some "bug reports" like this. If I remove those "!important", I'll get similar bug reports again -- I'm very sorry but I don't want that.

Instead, I made an option for "highly compatibile for other addons". See the configuration dialog of TST, "Appearance" panel. There is an option "Default (Specified by the Theme)" in built-in themes. If you choose the option, TST doesn't apply any "!important" rule for tabs. I believe that the option makes TST compatible with Tab Utilities and ColorfulTabs.

それらの「!important」指定は必要な物なのです。タブの外観がサードパーティ製のテーマによって変更される事があるのがその理由です。例えば、あるテーマが背景色を黒に、文字色を白に設定していた時、ツリー型タブのスタイル指定が部分的に適用されてしまうと、明るい背景色と白い文字の組み合わせになってしまうことがあります──これはとても読みにくいですよね。こういったケースの発生を防ぐために、私は「!important」指定を使う事を決めました。実際、私はそういう「バグ報告」を受け取った事があります。もしこれらの「!important」指定を削除したら、私は再びそういった報告を受け取る事になるでしょう──申し訳ありませんが、私はそれを望んでいません。

その代わりに、私は「他のアドオンとの互換性を高く保つ」選択肢を設けました。ツリー型タブの設定ダイアログの「外観」パネルを参照してください。ここでタブバーの表示スタイルとして「なし(テーマ本来の表示スタイル)」を選択すると、ツリー型タブは「!important」指定が付いたスタイル指定を適用しなくなります。これを選択する事で、ツリー型タブとTab UtilitiesやColorfulTabsの衝突は回避できるものと私は考えています。

タブをドメインごとにソートする機能が欲しい / 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はその両方の機能を提供します。ツリー型タブよりもそちらの方があなたにとって気に入るかもしれません。)

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

Tree Style TabMultiple 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が整理されていれば、こんな思いをしなくて済むのになあ。

ツリー型タブ 0.11.2010112601で機能を足したり引いたりした - Nov 26, 2010

今まではTree Style Tabでタブバーを横置き(上または下にタブバーを配置するモード)にした時特有の機能というのは特に設けていなかった、というか横置きで階層化されたグループ化なんて全然使いにくいし誰も使わないだろと思って割となおざりにしてたら、案外使われてるみたいで時々このモード特有のバグ報告を貰ってたわけですが、Opera 11でタブスタッキングとかいう機能が加わるとかで「そんなんXULでもできるわい!!! つうかもっと前からやっとるわい!!!」とカッとなって、タブが重なってるっぽく表示するようにしてみた。 (スクリーンショット)

種を明かしてしまうと、元々「折り畳まれたタブ」はvisibility: collapseで見えないようにしてたのを、collapseにせずにvisibleのままで親のタブの下にz-indexを調整して重ねるようにしたというだけ。諸々の事情でMinefieldでしかこの表示にはならないようになってる(Firefox 3.6だと今まで通り)。

このようにしたおかげで、

  • ツリーの折り畳み状態(子タブがあるかどうか)について、今までは見分ける術がタブのラベルに表示される「(3)」のような文字列と小さなtwistyだけだったので、縦置きタブバーではすぐ分かるけど横置きタブバーだと識別が困難だった。しかし今回の変更によって、タブの外形の変化で状態を簡単に識別できるようになった。
  • 折り畳まれた状態のタブをクリックできるようになった(元々、背後にあるタブにフォーカスが来ても大丈夫なように設計していたので、そのための変更というのは特にはしていない)。

というメリットを図らずも得られてしまった。

しかしIDEA*IDEAの記事の小さいスクリーンショットと動画だけ見てこういう表示にしたんだけど、もっと大きなスクリーンショットだと、実際は全然違う形だった。まあ、今更だからこのままいくけどさ……

あと、このリリースから「リンクをクリックした時にそれを自動的にタブで開く」系の機能と「ロケーションバーからの入力で常にタブを開く」系の機能を別のアドオンに分割することにした。

既にあったOpen Bookmarks in New Tabと並べて「新しくタブを開く系3兄弟」的な。

  • ちょっと探してみた限り、ほんとにこの機能だけを提供してくれるというアドオンを見つけられなくて、こういうものはTab Mix Plusとかの統合型のタブ拡張の一機能としてしか提供されていないようだった。
  • 統合型のタブ拡張はどれもこれもこの機能を持ってるせいでツリー型タブと衝突してそうだった。
  • これらの機能があるせいで、ツリー型タブは便利機能全部入りの統合型のタブ拡張を指向してると思われて、あれが欲しいこれが欲しいという機能追加の要望を受けてしまっていたのではないか? 僕はツリー型タブをそういう物として作りたくはない。

といった理由があっての決定です。多機能なのがいい人はツリー型タブを捨ててTab Kitあたりに乗り換えるといいと思います。

Google Chromeでツリー型タブ - Nov 10, 2010

ツリー型タブのGoogle Chrome版は作らないの?という問い合わせを一時期よくもらってたんだけど、とうとう出た。Google Chrome版Tree Style Tab。といっても僕が作ったんじゃなくて、ジェバンニが一晩でやってくれました。的な。

ただ、やはり僕が懸念していたように、形態としては「ツールバーのボタンをクリックしたらポップアップでツリーが出る」という物のようで、実際試してみても違和感があった…… 僕は「ツリーが常に見えている事」がTSTの常用には欠かせないと思っているので、この形の物はやはり辛い。

Side Tabs(起動オプション --enable-vertical-tabs で有効になる)が入っている最近のChromeでなら、あともうちょっと頑張ればなんとかなりそうな気がしなくもない。ページのタイトルの頭にスペースを挿入して擬似的にタブをインデント表示するとか。

omni.jarを展開してデバッグした話と、Minefield(Firefox 4)で起動時のセッション復元が働かなくなる問題について - Sep 27, 2010

最近のMinefieldのナイトリービルドで、ツリー型タブがあると前回終了時のセッションが復元されない(タブのタイトルだけ復元されて実際には空のページになる)という現象が起こっている。この問題の原因の究明のためにずいぶん遠回りをした。

  • 最初は、SSTabRestoringやSSTabRestoredイベントを監視してる所が悪いのかと思った。なのでツリー型タブのイベントリスナの所をコメントアウトしてみた。しかしそれでもまだ問題が起こる。
  • Minefieldの方が壊れてるのか?とも思ったけど、ツリー型タブを無効にしたら問題なくセッションが復元される。なのでどうもやはりツリー型タブが悪いみたい。

こういう時は、処理がどこで止まってしまっているのかを特定するのが僕が知ってる唯一の(そして多分一番ストレートな)原因調査の仕方だ。今回だったらセッション復元が止まってしまってるので、nsSessionStore.jsの中に沢山デバッグ用のdump()を埋め込んで、どこの時点でおかしくなっているのかを調べるという事になる。

が、Minefieldではそれが一筋縄ではいかなくなってた。

構成ファイルのほとんどを1つのアーカイブの中に入れてしまうというomni.jarという変更が反映されて、今までだったらcomponentsフォルダの中にそのまま置かれていたnsSessionStore.jsも、omni.jarの中に格納されている。なので上記のような調査法を取ろうとすると、omni.jarの中にあるファイルを書き換えないといけない。

ところが7-Zipではこのomni.jarを開くことができない。多くの場合、jarファイルはただのZIPアーカイブなので7-Zipのファイルマネージャで開いて中身を編集→再圧縮ということが簡単にできるんだけど、omni.jarの場合はアーカイブ自体が壊れていると判断されてしまって中身を見ることすら適わない。

検索してみたら同じようなことで悩んでる人が他にもいたみたいで、リンク先に書かれてる情報によるとExplzhを使えばomni.jarを開けるらしい。

ということで早速Explzhを入れてみた。Explzhでomni.jarを開いてみると、確かに中身を見ることができる。しかし、中にあるファイルを編集してエディタを終了すると、omni.jarの再圧縮に失敗してしまう。ファイル名を変えるとかファイルを1個だけ削除するとかするとなんとか編集後のファイルをアーカイブに含められたんだけど、その状態でMinefieldを起動すると、ファイルが部分的に読み込めなくなってウィンドウの背景が透明になってしまうとかの謎なトラブルが発生してしまった。Explzhでもomni.jarを部分的に変更しようとすると駄目みたいだ。

追記。Windows XP以降の「圧縮フォルダ」機能でもomni.jarを展開できるらしい。圧縮フォルダなんて微妙に不便だから使ってなかったのに、こんな所で役に立つとは……

まとめると、トラブルが起こらないようなomni.jarの編集方法は、こう。

  1. omni.jarを作業フォルダにExplzhで展開する。
  2. 必要な変更を行う(デバッグ用のコードを埋め込むなど)。
  3. 展開されたファイル群を7-Zip等でZIP形式で圧縮する。
  4. ファイル名をomni.jarに変更する。
  5. 4で作ったomni.jarで、Minefieldのomni.jarを置き換える。
  6. %localappdata%\Mozilla\Firefox\Profiles\プロファイル名\ の中にあるキャッシュファイルを消す。

この方法で、Minefieldが正常に起動する状態を保ちながらomni.jarの中にあるファイルに変更を加える事ができた。

nsSessionRestore.jsに大量のdump()を入れて調べてみた所、最初のタブ(現在のタブ)の復元が終わった後で次のタブを復元する時に、すぐに処理が終わってしまっていた。さらによく調べると、復元対象のタブを決定する時にもしタブのセッション情報の_tabStillLoadingというフラグがfalseになっていたら(=タブのセッションが復元完了していたら)、そのタブをセッションの復元対象から除外するという設計になっていた。

_tabStillLoadingというフラグには見覚えがあったのでツリー型タブのソースを検索し直してみたら、別のバグの対策でこのフラグを敢えてfalseにするような処理を入れていて、これが誤爆しているせいで上記の問題が起こっているようだった(本当はそのタブはまだセッションが復元されていない・読み込み中の状態なのに、_tabStillLoadingfalseにセットされてしまうため、タブがセッション復元の対象から除外されるようになってしまっていた)。

まとめると、こういう事だった。

  • Firefox 4 の最適セッションリストア原文)で行われた変更で、ブラウザ起動時のセッション復元が、すべてのタブを一度に復元するのではなく、3個ずつ復元するように変更された。
  • その時、まだ復元が完了していないタブがいつまでも「読み込み中」の状態に見えてしまうと格好が悪いので、タブの要素のbusy属性を取り除いて、一見すると既にタブの復元が完了しているかのように見せるようになった。その代わり、まだタブの復元が必要であることを示す_restoringというフラグをbrowser要素の方に立てるようになった。→Bug 602555でリファクタリングされて、また仕様が変わった。前述の「_restoringのフラグが立っている状態」に相当するのは「browser要素の__SS_restoreState1の時」になった。
  • ツリー型タブは、タブのbusy属性だけを見て、そのタブが読み込み完了しているかどうか・セッション復元中かどうかを判断して、読み込みが完了していると判断したタブのセッション情報の_tabStillLoadingを強制的にfalseにして、タブの読み込みが完了しているとnsSessionStoreに認識させるようにしていた。
  • そのため、Minefieldでは「一見すると読み込みが完了しているように見えるが、内部的にはまだセッション復元が完了しておらず読み込み中の状態である」タブまでもがツリー型タブによって「内部的にも読み込みが完了した状態である」という扱いになるようになってしまっていた。よって、タブのセッションが復元されないという現象が発生してしまっていた。

別のバグの対策用のコードの条件分岐にもうひとつ条件を足して、「一見すると読み込みが完了しているように見えるが、内部的にはまだセッション復元が完了しておらず読み込み中の状態である」というケースを判別するようにしたら、この問題は起こらなくなった。同じコードを他にもいくつかのアドオンで使っていたので、それらも合わせて修正しておくことにした。もし同じ事をやっている人が他にもいたら、十分気をつけて欲しい。

タブバーをドラッグしたらウィンドウが動くとかその辺のタイトルバーっぽい挙動を無効化する - Sep 15, 2010

ツリー型タブではタブバーをウィンドウの横に置く使い方を基本的には想定してるワケだけれども、普通にタブバーを縦型にするだけだと、Minefieldではタブバーをダブルクリックしたらウィンドウが最大化されるという謎の結果になってしまうことがある。

MinefieldではBug 555081で行われた変更により、ツールバーの空白の部分がウィンドウのタイトルバーと同じ扱いになるようになっている。ツールバーの空白部分をドラッグすればウィンドウが動くし、ダブルクリックすればウィンドウの最大化になる(Windowsの場合)し、ぴたすちおのようにタイトルバーを右クリックしたらウィンドウシェードするようなユーティリティを使っていれば、それも動く。

ただ、ウィンドウの横に移動されたタブバーのようにぱっと見ツールバーに見えない部分までもがこのような挙動になってしまうと、違和感があるし混乱の元ではある。また、ツリー型タブの場合はタブバーの空白の領域をドラッグするとタブバーの位置を変えられるという機能があるけれども、上記の通りの仕様なのでこのままではタブバーの位置を変えられないということにもなってしまう。こういう時、どうすればいいのか。

タイトルバーのように振る舞うツールバーの挙動は、chrome://global/content/bindings/toolbar.xml#toolbar-drag で定義されている。コードを見てみると、WindowDraggingUtils.jsmというモジュールを読み込んで自分自身をWindowDraggingElementという物に登録しており、こうして登録された要素がタイトルバーのように振る舞うようだ。じゃあこの初期化処理を無効化するか初期化処理で行われた結果を取り消してやればいいんじゃないか、と思ったけど、設計的にそれは無理だった。

仕方がないのでWindowDraggingUtils.jsmの方を見てみると、「タイトルバー上にあるボタン等をドラッグした時だけは上記のような動作にしないようにする」というのをどうやって実現しているのかが分かった。

  • Windowsでは、マウスのボタンが押下された時にMozMouseHittestというイベントが発行されている。
  • 任意で登録された関数(mouseDownCheck)がfalseを返した時か、クリックされた要素からその祖先までの間にドラッグ操作を受け付けそうな要素がある時は、preventDefault()している。
  • preventDefault()された場合、マウスのボタンがそもそも押下されなかったという扱いになるみたい。

端的に言うと、MozMouseHittestイベントをpreventDefault()すれば、ツールバーのタイトルバー的な振る舞いを無効化することができるということのようだ。

gBrowser.tabContainer.addEventListener(
  'MozMouseHittest',
  function(aEvent) {
    aEvent.preventDefault();
  },
  true
);

ただ、タブバー内で発生するMozMouseHittestイベントを常にpreventDefault()してしまうと、タブをクリックしてもタブが切り替わらないということになってしまう。preventDefault()するのは祖先要素にタブまたはクリック可能な要素が無い場合だけに制限しないといけない。

Minefield 4.0b6preでXUL要素とiframeの重ね合わせが鼻血出るくらい簡単になってた - Sep 11, 2010

ツリー型タブには「ポインタがタブバーを離れている時はタブバーを隠してor縮めて、ポインタがタブバーに近づいたら(フルサイズで)表示する」という機能がある。 (タブバーがコンテンツ領域に覆い被さる様子のスクリーンショット)

Firefox 4に向けて開発が進んでいるMinefield 4.0b6preでこの機能が動かなくなっていたので修正をしよう……と思ったら根本的に作りなおさなきゃいけなかった。でも以前のやり方に比べたらずっとスッキリと実装できるようになっていた。

これはそんなお話。

これまで

Firefox 3.6までは、上記の機能を実現するのにえらく苦労していた。

tabbrowser要素の仕様変更のまとめで過去に図解したけど、今までのFirefoxではタブバーとコンテンツ表示領域が1つのボックスの中に収まっていたので、ボックスの縦横の配置を変えるだけでタブバーを「縦置き」できていた。そうして「縦置き」したタブバーの幅を自動的に増やしたり減らしたりしてやりさえすれば、最も単純な「タブバーを自動で隠す」機能は実現できる。 (一番簡単な実現方法を採った場合のスクリーンショット)

ただ、実際にはそれだと実際使っててストレスを感じる。タブバーの幅が変化する度にタブバーによって押し潰される形でコンテンツ領域の幅が縮んでしまい見た目に激しくガタつくのと、それに加えて再描画のためにFirefoxが一瞬でも無反応になってしまう事がある、というのが多分その理由だろう。

じゃあタブバーの幅が増えた分をコンテンツ領域の上にかぶせてやればガタつきがなくなってイイよね、ということで上のスクリーンショットのような事をやろうとして、当時の僕はFirefoxの仕様に頭を抱える羽目になってしまった。

ネガティブマージンでは駄目だった

要素同士を重ねる、というと一番手っ取り早いのはネガティブマージンを使う方法だろう。タブバーにネガティブマージンを指定してやれば万事解決する……そう考えていた時期が僕にもありました。

(ネガティブマージンでタブがコンテンツ領域の下に潜り込んでしまった様子のスクリーンショット) 見るも無残。

どうも現行バージョンのGeckoはインラインフレームだけ特別な描画の仕方をしているらしく、iframeやbrowserの内容はオーバーレイのウィンドウのように他の内容より前に表示されるみたいだ。browser要素がDOMツリーに尽かされた後でDOMツリーに追加されたtab要素なら、browser要素よりも手前に描画されることもあるようだけど、基本的にはこうなると思っておいた方がいい。

ネガティブマージンで駄目ならposition:absoluteやらposition:fixedやらはどうなんだ、という代替案は当然出てくるだろうけど、これもやっぱり駄目だった。browserをz-index:1に、タブの方をz-index:2にという風にやっても、どう頑張ってもタブがbrowserの下に隠れてしまった。

panelは?

panelやmenupopupを使うと、OSのレベルで別のウィンドウを開いて任意の位置に重ねることができる。影や枠を表示しないようにすることもできるから、うまくやればこれが一番確実かもしれない。

ただ、自分で0から作る場合ならともかく、Firefoxのタブを後から改変するという場合には、これは激しくお勧めできない。Firefoxのタブ周りのDOMツリーを不用意にいじると、Firefoxの本来の構造を期待して開発されたアドオンが動かなくなってしまう可能性が高いからだ。

結局どうやったのか

アレも駄目これも駄目という感じだったので、Firefox 3.6以前では結局、他のアドオンに対して与える影響が一番少なそうなやり方として、いくつかのテクニックの組み合わせでそれっぽく見せるようにしてみた。

まずタブバーの幅を普通に増やす。 (タブバーの幅が増えた状態のスクリーンショット)

それだけだとコンテンツ領域が押し潰されてしまうので、そうならないようにネガティブマージンでappcontentあたりの幅を広げてレイアウトを維持する。 (コンテンツ領域の幅を広げた状態のスクリーンショット)

次にnsIContentViewerのmoveメソッドで描画内容をずらす。このメソッドは、フレームの内容の描画位置を任意の座標分平行移動する物だ。 (描画内容をずらした状態のスクリーンショット)

仕上げとして、nsIContentViewerのmoveメソッドで描画位置を変えたせいでレンダリングされていない「タブバーと重なり合う部分」を、canvasのdrawWindowで描画する。 (canvasで半透明の効果を再現した状態のスクリーンショット) スクロールしてる場合やフルズームが使われている場合に位置をうまく合わせるのが難しいけど、なんとか頑張った。

Minefield 4.0の古いベータへの対応

ちょっと前までのMinefieldでも、基本的にはこれと同じ事をやってた。 tabbrowser要素の仕様変更のまとめで説明している通り、タブバーそのものはposition:fixedで固定して位置を合わせていて、かつてタブバーがあった所に挿入したダミーの要素と実際のタブバーとの表示サイズを同期させているという点が異なるけど、browser(iframe)とタブが重ならないように工夫を凝らしているという点では変わりはなかった。

これから

そんな感じで今までやってたんだけど、Minefield 4.0b6preをアップデートして試しに機能をONにしてみたら、上記の解決策の重要な要素の1つである「nsIContentViewerのmoveメソッドで描画内容をずらす」が効かなくなってた。 (描画内容をずらせていないためにおかしな表示になってしまっている様子のスクリーンショット)

これではタブバーの幅が変わる度にコンテンツ領域がガタついてしまうという問題を回避できない。

もはやこれまでか。そう思った僕を救ったのは、別の(ツリー型タブ)の不具合によって起こっていた現象でした。

先述の通り、Minefield用には既にタブバーをposition:fixedでレイアウトするという変更を反映してた。それが原因で、TabsToolbarの中に配置されたツールバーボタンが、タブバーが自動的に隠された状態であっても表示されたままになってしまうという現象が同時に発生していた。 (問題が起こっている様子のスクリーンショット)

……ん? ちょっと待てよ! なんでその位置にそのボタンが見えてるわけ?! browserの下に隠れてない!?

検証してみたところ、いつ行われた変更によるものなのかは分からないけど、Minefieldではいつの間にか、前述した「browserやiframeの内容は常に最前面に描画されてしまう。それらと重なる位置に置かれたXUL要素はbrowserやiframeの下に隠れてしまう。」という問題が起こらなくなっているようだ。

そこまで分かれば話は早い。もう前述のような凝ったことをしなくても、普通にposition:fixedで配置してbackground:rgba(0, 0, 0, 0.25)にすればもうそれだけで、「半透明のタブバーの下にコンテンツ領域が透けて見える」状態になるということだ。 (canvasによる再現ではない本当の半透明が実現された様子のスクリーンショット) こうしてひとまず現状のMinefieldには対応することができた。

まとめ

  • Minefieldでは、position:fixed等で任意のXUL要素をコンテンツ領域の上に重ねて配置できるようになった。ポジショニングを気軽に使えるようになった。
  • 今まで必要だった、制限の回避のための工夫は、もういらない(多分)。

いい時代になったものですね。

Page 4/243: « 1 2 3 4 5 6 7 8 »

Powered by blosxom 2.0 + starter kit
Home

カテゴリ一覧

過去の記事

1999.2~2005.8

最近のつぶやき