宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能!
タブバーがtabbrowser要素の中から取り出されて1つのツールバーになったということで、タブ関係の挙動を変える系のアドオンが死屍累々なんじゃないかと不謹慎にもwktkしてるわけですけれども。特に影響が大きくて話としても「あーそりゃそうなるわな」ってのが分かりやすいのは、やはりタブバーの表示位置の変更機能ですよね。
今までは、Firefoxのメインウィンドウの中身は簡単に言えばこんな要素構造になってた。
<toolbox>
<toolbar/>
</toolbox>
<tabbrowser>
<tabbox orient="vertical">
<tabs orient="horizontal">
<tab/>
<tab/>
</tabs>
<tabpanels>
<browser/>
<browser/>
</tabpanels>
</tabbox>
</tabbrowser>
XULのレイアウトは主にMozillaの関係者からCSS3に提案中のflexible box layoutに基づいてるんだけど、
-moz-box-orient: horizontal
(XUL要素の属性指定だとorient="horizontal"
)だとボックスの中身が横に並ぶ。-moz-box-orient: vertical
(XUL要素の属性指定だとorient="vertical"
)だとボックスの中身が縦に並ぶ。ordinal
の値)の順にボックスが並べ替えられて表示される。これだけの事を組み合わせれば、タブバーの位置を上下左右好きな位置に移動できた。
という具合。
ところが、bug 347930のパッチで要素構造が以下のようにガラッと変わった。
<toolbox>
<toolbar/>
<toolbar id="TabsToolbar">
<tabs orient="horizontal">
<tab/>
<tab/>
</tabs>
</toolbar>
</toolbox>
<tabbrowser>
<tabbox orient="vertical">
<tabpanels>
<browser/>
<browser/>
</tabpanels>
</tabbox>
</tabbrowser>
こうなると、単純にボックスの並び順やら並べる方向やらを変えただけではタブバーの位置を動かせない。
ドン詰まりですね。
alice0775さんの調べによると、タブバーの位置を変える機能を持ってる他のアドオンでは、tabsを一旦DOMツリーから取り外して別の位置に挿入し直すという方法で、タブバーの表示位置変更を実現しているらしい。
しかしこのやり方だと、tabsがDOMツリーから取り外されるより前に他のアドオンが行った初期化処理の効果がリセットされてしまう場合がある。リンク先のエントリでいくつか挙げられてる懸念がそれ。
本当だったらFirefox本体の方でなんとか面倒を見て欲しい(タブバーの位置変更を行う機能を持たせて、位置が変わる前と後でイベントを発行するようにするとか)所なんだけど、責任者の人達をIRCで英語で説得する自信は全く無いチキンでTOEICスコアめためたで英語音痴な僕は、アドオン側でなんとかする方法を考えないといけない。しかし、最も単純なやり方(DOMツリーの改変)だと他のアドオンとの競合という点で弊害が大きすぎる。
そういうわけで、ちょっと考えてみました。DOMツリーをいじらずにタブバーの位置を変える方法を。
ヒントになったのは、XUL/Migemoの「タブバーの下に検索バーを移動する」機能や、Unified Sidebarの「サイドバーを縦型タブバーの下半分に表示する」機能の実装方法。
これらのアドオンでは「検索バーやサイドバーを表示したい位置にmarginやpaddingでスペースを設けて、検索バーやサイドバーをCSS2のポジショニングでその位置に重ねる」という方法で、DOMツリーを改変することなく要素の表示位置だけを変更している。また、ウィンドウの大きさなどが変わった時には、resizeイベントを捕捉して表示位置や要素の表示サイズを自動調整するようにしている。
ツリー型タブのMinefield 3.7a4pre対応でも、基本的にはそれと同じ方法を使う事にした。ただ、タブバーの幅をリサイズできるようにするsplitterを、ポジショニングで表示位置を変えられた状態向けにゼロから作りなおすのは面倒だったので、tabboxの中にダミーのhbox要素を挿入して、splitterは普通にXULのsplitterを使い続ける事にした。
<toolbox>
<toolbar/>
<toolbar id="TabsToolbar">
<tabs orient="horizontal">
<tab/>
<tab/>
</tabs>
</toolbar>
</toolbox>
<tabbrowser>
<tabbox orient="vertical">
<hbox/>
<splitter/>
<tabpanels>
<browser/>
<browser/>
</tabpanels>
</tabbox>
</tabbrowser>
このようにした上で、
とする事で、ぱっと見は今までと同じような挙動を実現しつつ、タブ周りのDOMツリーは一切破壊しないという実装になった。
ツリー型タブのやり方とTab Mix Plus等のやり方のどっちがいいかは、一概には言えない。どちらにもメリットとデメリットがある。
ただ僕は、ツリー型タブで採用したやり方の方が「他のアドオンが全く動かなくなってしまうような衝突の仕方はしなくて、仮に衝突しても最小限の労力でなんとか回避できる可能性が高い」と信じている。
現在Firefox本体の側には、3.6以前のバージョンのFirefox向けに書かれたアドオンについて、Minefield 3.7a4pre以降でもそのまま動くようにするためのパッチも取り込まれている。ちょっとアドオンの作り方に気をつけさえすれば、タブをダブルクリックした時の挙動を変えるとか、リンクから開いたタブの位置を制御するとかいった単機能のアドオンは、ほとんど何も手を加えずにMinefield 3.7a4pre以降に対応できるようになってる。
しかしながら、Tab Mix Plusが現在採用している(らしい)DOMノードを切り貼りするやり方では、「ほっといても他のアドオンがちゃんと動いてくれる」ようにはなりにくい。「DOMノードの切り貼りでタブバーの位置が変更された事」を検知して何らかの特別な初期化処理を行うようなコード、を他のアドオンの側に加えてもらわないと互換性を保てない。僕は、僕のアドオンと競合しないで使えるようにするために、他のアドオンの作者がわざわざ気を使ってくれるとは思えない。僕が作ってる物が、そこまで他のアドオン作者から特別視してもらえる存在だとは、思えない。
なので、僕がアドオンを作る時はなるべく、他のアドオンの側に変更が必要になるような作りにはしないでおこうと思ってる。どうしてもそうなる時は、APIを提供してAPI経由でスッキリと連携できるようにしようと思ってる。そういう謙虚というか悲観的な姿勢が、「ユーザがどんなアドオンと組み合わせて使うかは全く分からない」アドオンを作る上では必要なんじゃないかと思ってる。
タイトルが「3.4a4pre」になってます。
File > Print Preview としたときにダミーのhbox要素とsplitter要素が非表示にならないようです。
どちらも修正しました。
Print Previewの問題は、これまでもスプリッタだけ表示されっぱなしだったかも。
の末尾に2020年11月30日時点の日本の首相のファミリーネーム(ローマ字で回答)を繋げて下さい。例えば「noda」なら、「2010-03-29_minefield.trackbacknoda」です。これは機械的なトラックバックスパムを防止するための措置です。
writeback message: Ready to post a comment.