Home > Latest topics

Latest topics > Minefield 3.7a4preのタブバーの仕様変更に対してツリー型タブで取った対応方法

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

宣伝2。Firefox Hacks Rebooted発売中。本書の1/3を使って、再起動不要なアドオンの作り方のテクニックや非同期処理の効率のいい書き方などを解説しています。既刊のFirefox 3 Hacks拡張機能開発チュートリアルと併せてどうぞ。

Firefox Hacks Rebooted ―Mozillaテクノロジ徹底活用テクニック
浅井 智也 池田 譲治 小山田 昌史 五味渕 大賀 下田 洋志 寺田 真 松澤 太郎
オライリージャパン

Minefield 3.7a4preのタブバーの仕様変更に対してツリー型タブで取った対応方法 - Mar 29, 2010

タブバーが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")だとボックスの中身が縦に並ぶ。
  • -moz-box-ordinal-groupの値(XUL要素の属性指定だとordinalの値)の順にボックスが並べ替えられて表示される。

これだけの事を組み合わせれば、タブバーの位置を上下左右好きな位置に移動できた。

  • 初期状態では、tabboxのorientがverticalで、tabsにもtabpanelsにもordinalは指定されていないので、タブバーは上に来る。
  • tabboxのorientをhorizontalにしてtabsのorientをverticalにすれば、タブバーが左に来る。
  • tabsのordinalを2、tabpanelsのordinalを1にすれば、タブバーが下に来る。
  • 両方を同時に指定すれば、タブバーが右に来る。

という具合。

これから

ところが、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>

こうなると、単純にボックスの並び順やら並べる方向やらを変えただけではタブバーの位置を動かせない。

  • toolboxの中にtabsがあるので、ordinalではtabbrowserより下にtabsを持って来れない。無理に持ってこようとするとtoolbox全体がtabbrowserの下に来てしまう。
  • toolboxの中にtabsがあるので、orientではtabbrowserの横にtabsを持って来れない。無理に持ってこようとするとtoolbox全体が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>

このようにした上で、

  • hboxを含むtabboxの内容を、Firefox 3.6までの手法でレイアウトして、tabsの表示用のスペースを確保する。
  • hboxの上に同じ大きさでtabsを重ねる。
  • splitterによってhboxがリサイズされた時は、tabsの位置や大きさを自動的に更新する。

とする事で、ぱっと見は今までと同じような挙動を実現しつつ、タブ周りのDOMツリーは一切破壊しないという実装になった。

どっちのやり方の方がいいのか

ツリー型タブのやり方とTab Mix Plus等のやり方のどっちがいいかは、一概には言えない。どちらにもメリットとデメリットがある。

ただ僕は、ツリー型タブで採用したやり方の方が「他のアドオンが全く動かなくなってしまうような衝突の仕方はしなくて、仮に衝突しても最小限の労力でなんとか回避できる可能性が高い」と信じている。

現在Firefox本体の側には、3.6以前のバージョンのFirefox向けに書かれたアドオンについて、Minefield 3.7a4pre以降でもそのまま動くようにするためのパッチも取り込まれている。ちょっとアドオンの作り方に気をつけさえすれば、タブをダブルクリックした時の挙動を変えるとか、リンクから開いたタブの位置を制御するとかいった単機能のアドオンは、ほとんど何も手を加えずにMinefield 3.7a4pre以降に対応できるようになってる。

しかしながら、Tab Mix Plusが現在採用している(らしい)DOMノードを切り貼りするやり方では、「ほっといても他のアドオンがちゃんと動いてくれる」ようにはなりにくい。「DOMノードの切り貼りでタブバーの位置が変更された事」を検知して何らかの特別な初期化処理を行うようなコード、を他のアドオンの側に加えてもらわないと互換性を保てない。僕は、僕のアドオンと競合しないで使えるようにするために、他のアドオンの作者がわざわざ気を使ってくれるとは思えない。僕が作ってる物が、そこまで他のアドオン作者から特別視してもらえる存在だとは、思えない。

なので、僕がアドオンを作る時はなるべく、他のアドオンの側に変更が必要になるような作りにはしないでおこうと思ってる。どうしてもそうなる時は、APIを提供してAPI経由でスッキリと連携できるようにしようと思ってる。そういう謙虚というか悲観的な姿勢が、「ユーザがどんなアドオンと組み合わせて使うかは全く分からない」アドオンを作る上では必要なんじゃないかと思ってる。

分類:Mozilla > 拡張機能 > treestyletab, , , , , , , 時刻:00:59 | Comments/Trackbacks (3) | Edit

Comments/Trackbacks

typo

タイトルが「3.4a4pre」になってます。

Commented by kuy at 2010/03/29 (Mon) 02:33:44

Minefield 3.7a4pre + tree_style_tab-0.10.2010032802について

File > Print Preview としたときにダミーのhbox要素とsplitter要素が非表示にならないようです。

Commented by Alice0775 at 2010/03/29 (Mon) 02:35:30

no title

どちらも修正しました。
Print Previewの問題は、これまでもスプリッタだけ表示されっぱなしだったかも。

Commented by Piro at 2010/03/29 (Mon) 03:40:32

TrackBack ping me at


の末尾に2014年1月19日時点の日本の首相のファミリーネーム(ローマ字で回答)を繋げて下さい。例えば「noda」なら、「2010-03-29_minefield.trackbacknoda」です。これは機械的なトラックバックスパムを防止するための措置です。

Post a comment

writeback message: Ready to post a comment.

2014年1月19日時点の日本の首相のファミリーネーム(ひらがなで回答)

Powered by blosxom 2.0 + starter kit
Home

カテゴリ一覧

過去の記事

1999.2~2005.8

最近のつぶやき

オススメ

Mozilla Firefox ブラウザ無料ダウンロード