たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能!
Tree Style TabとMultiple Tab Handlerのドラッグ&ドロップ周りのコードを色々書き直した。
発端は、「Tab Utilitiesと一緒に使うとタブのドラッグ&ドロップが期待通りに動かない」という報告だった。しかし、「また衝突かよー」と思いながらメールの内容を読むと、想像していたのとはちょっと状況が違った。
僕はてっきり、Tab Utilitiesのイベント処理とツリー型タブのイベント処理がかちあって変な事になってるんだとばかり思ってたんだけど、そうではなくて、Tab Utilitiesが提供する「複数のタブを選択してまとめてドラッグ&ドロップする」機能で複数のタブを1つのタブの上にドロップしても、選択されていたタブのうち1つしかドロップ先のタブの子タブにならない、という状況だった。その人はすでにTab Utilitiesの作者にも問い合わせていたようで、Tab Utilitiesの作者の回答に「ツリー型タブにマルチプルタブハンドラのためのコードしか含まれていないのがそもそもの問題だ。ツリー型タブの方で修正してもらってくれ。」みたいなコメントがあったそうだ。
それでTab Utilitiesを見てみたら、確かに複数のタブを選択する機能があったんだけど、その時のタブの情報の受け渡しにHTML5のドラッグ&ドロップのイベントの複数のデータの指定の仕組みが使われているようだった。
という事情があって、マルチプルタブハンドラではドラッグ操作のイベントそのものには介入しないようにしてたんだけど、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が整理されていれば、こんな思いをしなくて済むのになあ。
今まではTree Style Tabでタブバーを横置き(上または下にタブバーを配置するモード)にした時特有の機能というのは特に設けていなかった、というか横置きで階層化されたグループ化なんて全然使いにくいし誰も使わないだろと思って割となおざりにしてたら、案外使われてるみたいで時々このモード特有のバグ報告を貰ってたわけですが、Opera 11でタブスタッキングとかいう機能が加わるとかで「そんなんXULでもできるわい!!! つうかもっと前からやっとるわい!!!」とカッとなって、タブが重なってるっぽく表示するようにしてみた。
種を明かしてしまうと、元々「折り畳まれたタブ」はvisibility: collapseで見えないようにしてたのを、collapseにせずにvisibleのままで親のタブの下にz-indexを調整して重ねるようにしたというだけ。諸々の事情でMinefieldでしかこの表示にはならないようになってる(Firefox 3.6だと今まで通り)。
このようにしたおかげで、
というメリットを図らずも得られてしまった。
しかしIDEA*IDEAの記事の小さいスクリーンショットと動画だけ見てこういう表示にしたんだけど、もっと大きなスクリーンショットだと、実際は全然違う形だった。まあ、今更だからこのままいくけどさ……
あと、このリリースから「リンクをクリックした時にそれを自動的にタブで開く」系の機能と「ロケーションバーからの入力で常にタブを開く」系の機能を別のアドオンに分割することにした。
既にあったOpen Bookmarks in New Tabと並べて「新しくタブを開く系3兄弟」的な。
といった理由があっての決定です。多機能なのがいい人はツリー型タブを捨ててTab Kitあたりに乗り換えるといいと思います。
半分眠ったまんまで作業してたのでしょーもないregressionを仕込む→修正して公開→またregressionということを繰り返した結果、既に0.13.3になってしまったわけですが、バージョン0.13.0で結構大きくいじりました。機能的には全然変わってないですが。
nodesFromRect()
を使うようにしたので、見えているスクロール位置から検索を始める処理が相当速くなりました。nodesFromRect()
の効果と合わせて、Minefield 4.0b2preではページ内検索のストレスがほとんど無くなったと思います。Minefieldで検索が速くなったのは、Bug 39098 – Elements with visibility:hidden, visibility:collapse, or display:none get copied to the clipboardがfixされたおかげです。
toString()
で文字列にすると、CSSで非表示になっている要素のテキストまで一緒に取得されてしまうのですが、その後rangefindで検索する時は非表示のテキストは検索対象にならないため、場合によってはヒット箇所が飛ばされてしまったり検索が止まってしまったりという問題が起こります。DOMWindow.QueryInterface(Ci.nsIInterfaceRequestor)
.getInterface(Ci.nsIWebNavigation)
.QueryInterface(Ci.nsIInterfaceRequestor)
.getInterface(Ci.nsISelectionDisplay)
.QueryInterface(Ci.nsISelectionController)
.checkVisibility(textNode, 0, textNode.nodeValue.length)
というやり方で個々のテキストノードの可視・不可視の状態を判別して不可視のテキストを除外した結果を取得して、正規表現のマッチングに使うようにしていました。Minefield 4.0b2preにXUL/Migemo 0.13.xを入れてMXRのページでページ内検索してみると、効果の程がよく分かると思います。僕は、今すぐにでもFirefox 3.6を窓から投げ捨ててしまいたくなりました。
あとはJägerMonkeyが入ってくれれば……
ところで、他のアドオンからXUL/MigemoのAPIを呼び出す時はちょっと注意が必要になってます。
migemo
オブジェクトから機能を呼び出す時には常にシステム辞書の内容だけを返すように仕様を変えました。Components.utils.import('resource://xulmigemo-modules/service.jsm')
でユーティリティを読み込んでXMigemoCore
の各メソッドを呼ぶか、Cc['@piro.sakura.ne.jp/xmigemo/factory;1'].getService(Ci.xmIXMigemoFactory).getService('ja')
てな感じでXPCOMコンポーネントを直接呼び出すかする必要があります。XMigemoCore
でもxmIXMigemoCoreでもどっちにしても、これらが持つ機能で正規表現を生成する時は戻り値は常に文字列(正規表現のソース文字列)になるので、その都度new RegExp()
してやる必要があります。migemo
のメソッドを使って問題ありません。XUL/MigemoのUI周りでもそうしてます。タブバーが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経由でスッキリと連携できるようにしようと思ってる。そういう謙虚というか悲観的な姿勢が、「ユーザがどんなアドオンと組み合わせて使うかは全く分からない」アドオンを作る上では必要なんじゃないかと思ってる。
ツリー型タブに対して表題のような要望が寄せられることが何度かある。ツリーと関係ないからツリー型タブにそういう機能を入れる気はないんだけど、まあそういうニーズはあるんだろうなというのは理解できる。なので以前にuserChrome.cssでそれっぽくする方法を考えてみたりもした。その時の結論としては「ちゃんとアドオンにしないと駄目だね」という感じだったんだけど、結局誰もアドオン化してくれてなかったようだったので、仕方がないから自分で作った。
このアドオン自体はタブを縦置き表示する機能は持ってません。単にサイドバーの表示位置を変えるだけです。タブを縦置きするにはuserChrome.cssで頑張るか以下のアドオンを使って下さい。
他にもタブを縦置きするアドオンがあれば、なるべく連携するようにはしたいので、このエントリにコメント付けるなどして教えて下さい。
マルチプルタブハンドラについて「複数のタブをリロードする時、全部一気に読み込み始めるんじゃなく、3秒ずつ位間を空けて読み込むような機能を付けて欲しい」という風な要望をもらったんだけど、マルチプルタブハンドラに依存する機能にするよりは単機能で使えるようにしといた方がいいような気がしたので、サクッと作って公開した。
reloadTab()
メソッドとreloadAllTabs()
メソッドをゴッソリ入れ替えてるので、この辺を触ってるアドオンがもしあったら衝突するかも。こういう風にブラウザそのものの挙動を変えてしまうアドオンはChrome(Chromium)では作るのは難しいような気がするけど、実際にチャレンジしたわけではないので、ほんとのところはどうなんだろ。
Tree Style Tab 0.8.2009122501でTabberwocky用のコードを入れました。とりあえず、選択範囲のリンクをタブで開く機能と、新しいタブを現在のタブのすぐ隣に開く機能については、ちゃんと動くことを確認してます。他にうまく動かない機能があったら言って下さい。Tab Mix Plusに比べたら全然コードの量も少ないんで、たぶん対応できると思う。
Tab Mix Plusと組み合わせた時の問題もどうにかしようと思ったんだけど、見てみたらTMPの中にTST用のコードが入ってたので、さっくり諦めた。お互いがお互いに手を出すともはや収拾が付かなくなるから。なのでちょうどいい機会だと思って、TMPのフォーラムに「いいかげんこの状況なんとかしようよ」的な提案を書き込んでみた。そのついでに、ソースコード中で「PUBLIC API」と書いておきながら説明を書き忘れてたAPIをドキュメントに追加した。
他のアドオンと連携を取りやすくするためのAPIを加えるのはやぶさかじゃないので、要望があれば是非言ってください。最近の例では、TreeStyleTabService.currentTabbarPosition
やTreeStyleTabService.treeViewEnabled
はメールで「こういう事をしたいんだけどどうすればいいのさ」と問い合わせを受けたので追加したAPIです。
ツリー型タブはバグをつぶし始めたらきりがなくなってきたので、適当なところで打ち切ってリリースしました。バグ報告への返信で「I'll update as soon.」とか書いちゃったからというのもある。
画面の描画内容をロックするアレについては、結局ライブラリ化しました。window['piro.sakura.ne.jp'].stopRendering.stop()
で描画停止、window['piro.sakura.ne.jp'].stopRendering.start()
で再開します。複数の機能で停止/再開をネストしても大丈夫なように、呼び出し回数をカウントするようにしてあります。start()
し忘れると変なことになるので注意して下さい。
他にもいくつかAPIを追加したので、自作アドオンと連携して動作させてみたい人は参考にして下さい。
Firefoxでは、タブがセッション情報も伴って復元された時に、SSTabRestoring
とSSTabRestored
という2つのイベントが発行される。イベントのoriginalTarget
はいずれも復元されたタブの要素で、SSTabRestoring
はセッション復元処理が走ったけれどもタブの読み込みは完了していない段階、SSTabRestored
はタブの読み込みが完了した段階で発行される。
これらのイベントが発行される場面は、3つある。
この3つの場合を、特に1とそれ以外とを判別したい、その方法を考えてみたよ、というのがこのエントリの主題です。
例えばツリー型タブでは、タブの親子関係が変更された時のインデントの変更やツリーの折りたたみ時にアニメーション効果を適用している。しかしながら、Firefoxのセッション復元時に複数のタブのツリー構造を一気に変更する場合には、いちいちアニメーションしてたら重くてしょうがない。なので、この時だけはアニメーション効果を適用しないようにしたいと僕は思った。
しかしながら、前述のSSTabRestoring
とSSTabRestored
からは、そのイベントが発行されたのが上記の3つの場面のうちいずれなのかが分からない。どの場面でイベントが発行されたのかを判別するには、他の情報も参照する必要がある。
実は1の場合については、セッションが復元される時にObserverServiceに登録したオブザーバに対してsessionstore-windows-restored
というメッセージが通知される。なので、これを監視すればいいんじゃないか?と、最初のうちは考えてた。
でも、話はそう単純には済まなかった。実際にイベントを監視してみると、セッション復元時には以下のような順番でイベントが発行されていることが分かった。
SSTabRestoring
イベントが発行される。sessionstore-windows-restored
が通知される。SSTabRestoring
イベントが順番に発行される。SSTabRestored
イベントが読み込みの終わった物から発行される。3と4はこの通りにならないこともあって、あるタブのSSTabRestoring
が発行されてすぐに読み込みが完了したタブについては、次のタブのSSTabRestoring
が発行される前にSSTabRestored
が発行される場合もある。
一番致命的なのは、複数タブのセッション復元が始まったことは通知されるのに、全部のタブのセッション復元が終わったことは通知されないという点だ。
sessionstore-windows-restored
が通知されたらその後に発行されたSSTabRestoring
は全部ウィンドウ単位のセッション復元の一部なんだな、と判断してしまうと、例えば10個のタブを開いたウィンドウのセッションを復元した後、1つタブを開いて、閉じて、開き直した時、そのタブまで「ウィンドウ単位のセッション復元の一部」と誤爆してしまう。SSTabRestored
が発行されるまでの間にSSTabRestoring
が発行されたタブ」がウィンドウ単位のセッション復元なんだな、と判断してしまうと、後続のタブのSSTabRestoring
よりも前にSSTabRestored
が発行された時に、セッション復元が終わってないのに終わったと見なされてしまう。という具合で、「ウィンドウ単位でのセッション復元の終わり」がいつなのかが分からないと、誤爆しまくりで全然役に立たない。
また、重ねて困ったことに、sessionstore-windows-restored
の通知はsubjectがnull
なので、どのウィンドウでセッション復元が開始されたのかすらオブザーバ側からは分からない。別のウィンドウでセッション復元がはじまった時に来た通知を見て「これからこのウィンドウで開き直されるタブは全部、ウィンドウ単位のセッション復元の一部なんだな」と判断してしまってはいけない。
dump()
をコードの中に埋め込んで調べたところ、nsSessionStore.js内の各処理とイベントは、以下のような順番で起こっているらしいということが分かった。
SSTabRestoring
が発火sessionstore-windows-restored
が通知されるSSTabRestoring
が発火×タブの個数分SSTabRestored
が発火×タブの個数分SSTabRestored
が発火したら、すべてのタブの復元が完了このうちnsSessionStore::restoreHistoryPrecursor()やnsSessionStore::restoreHistory()やnsSessionStore::restoreDocument_proxy()は、タブを1つ復元するだけの時にも使われてる。
よくコードをよく読むと、nsSessionStore::restoreHistoryPrecursor()の中で「復元するタブの数だけ新しくタブを開く」「それらのタブのtab.linkedBrowser.parentNode.__SS_data._tabStillLoading
をtrue
にセットする」という処理が行われて、その後でsessionstore-windows-restored
がオブザーバに通知されていた。(このtab.linkedBrowser.parentNode.__SS_data._tabStillLoading
は、タブの復元が完了した段階でundefined
になる。)
ということは、sessionstore-windows-restored
が通知された時にウィンドウ内の全部のタブを調べて、tab.linkedBrowser.parentNode.__SS_data._tabStillLoading
がtrue
であるタブが2つ以上ある(復元待ちのタブが複数ある)なら、そのウィンドウでこれからウィンドウ単位のセッション復元が行われようとしている、と考えてよいわけだ。
で、SSTabRestored
が発行される度に復元待ちのタブの数を確認して、復元待ちのタブの数が0になったら、ウィンドウ単位でのセッション復元が終わったと判断できる。
厳密には、「ウィンドウ単位でのセッションの復元中に別途タブを1個だけ復元した」という場合にもそのタブが「ウィンドウ単位のセッション復元の一環で復元された」と見なされてしまうので、この方法にも穴はある。たくさんのタブのツリー構造を一気に変更した時にアニメーションでクソ重くなるのを避けたい、という僕の目的ではこれで必要十分なので、これ以上は追求してない。
以上をコンパクトにまとめると、こんな感じになる。
var ObserverService = Cc['@mozilla.org/observer-service;1']
.getService(Ci.nsIObserverService);
var observer = {
restoringWindow : false,
getRestoringTabsCount : function() {
return Array.slice(gBrowser.mTabContainer.childNodes)
.filter(function(aTab) {
var owner = aTab.linkedBrowser;
var data = owner.parentNode.__SS_data;
return data && data._tabStillLoading;
}).length;
},
observe : function(aSubject, aTopic, aData) {
if (aTopic == 'sessionstore-windows-restored')
this.restoringWindow = this.getRestoringTabsCount() > 1;
},
handleEvent : function(aEvent) {
switch (aEvent.type) {
case 'load':
window.removeEventListener('load', this, false);
window.addEventListener('unload', this, false);
gBrowser.addEventListener('SSTabRestoring', this, false);
gBrowser.addEventListener('SSTabRestored', this, false);
return;
case 'unload':
ObserverService.removebserver(this, 'sessionstore-windows-restored');
window.removeEventListener('unload', this, false);
gBrowser.removeEventListener('SSTabRestoring', this, false);
gBrowser.removeEventListener('SSTabRestored', this, false);
return;
case 'SSTabRestoring':
this.onTabRestoring(aEvent);
return;
case 'SSTabRestored':
this.onTabRestored(aEvent);
return;
}
},
onTabRestoring : function(aEvent) {
var tab = aEvent.originalTarget;
if (this.restoringWindow) {
// ウィンドウ単位でのセッション復元時の処理
}
else {
// タブが個別に開き直された時の処理
}
},
onTabRestored : function(aEvent) {
if (this.restoringWindow)
this.restoringWindow = this.getRestoringTabsCount() > 0;
}
};
window.addEventListener('load', observer, false);
ObserverService.addObserver(observer, 'sessionstore-windows-restored', false);
セッションストアAPIを使ってタブにいろんな情報を紐付けて、その情報に基づいてあれこれしたい人には、役に立つんじゃないでしょうか。(でもそんな変なことやってる人はほとんどいないんだろうなー)
XUL/Migemo 0.12.xで、機能を他のアドオンとかから呼び出すためのAPIを刷新してみたよ。
古いAPI(はてなブックマーク拡張とかが使ってくれてるやつ)は僕自身が色々よく分からないまま作った物だったために、引数を文字列で渡さないといけないとか戻り値も正規表現オブジェクトではなく文字列だとか、色々と使い勝手が悪かったと思う。メインウィンドウ以外では呼び出す時にいちいちXPConnect使わないといかんし。
新しいAPIは、それに比べたらものっそシンプルになった。XPConnect使わなくてもmigemo.getRegExp('hoge')
とか書くだけで使えるし、戻り値もすぐに使える正規表現オブジェクトが返ってくるし。互換性を保つために旧APIはそのまま残してあるので、旧APIを使ってるアドオンが動かなくなるということはないけど、今後は使うなら新APIの方を使うのがお勧めです。
で、このAPIはWebページ内のスクリプトでもCPUの使用率を取得できるようにするAPIを提供する例のアドオンの技術の応用なので、Webページ内のスクリプトからもXUL/Migemoの機能を利用できてしまいます。
ただしスクリプトの実行権限の関係で、上記のmigemo.getRegExp('hoge')
のような、正規表現オブジェクトを直に受け取る機能は使えません。代わりにJavaScript/Migemo互換の、正規表現のソース文字列を返すAPI migemo.query('hoge')
などを使う必要があります。
XUL/Migemo 0.12.2以降が入ってる環境でこのページを表示してれば、以下のデモを試せるはず。
ページ内検索系のメソッドもあるんだけど、多分使いでがなさそうなので解説は用意してないです。
すでに上でもリンクしてるけど、エンジンごとページ内に埋め込めるJavaScript/Migemoという実装もあるから、XUL/Migemoを入れてるFirefoxユーザでないと使えないこのAPIってなんか意味あんの?と言われそう。深くはツッコまないでください。
以下、補足事項。
当初このエントリでは、「Webページ上のスクリプトからもmigemo.getRegExp('hoge')
のようにして正規表現を取得して利用できる」という風な書き方をしてたけど、これは大間違いだった。戻り値の正規表現オブジェクトが生成された実行コンテキストがUniversalXPConnect特権のある場所なのに対して、呼び出し元は特権のない普通のWebページ上であるため、それぞれの権限が違うので本来ならその正規表現の各メソッドは実行できないのが正しい。
ただ、Gecko 1.9.1(Firefox 3.5)以前のバージョンにはバグがあって、上記のようなセキュリティのチェックが働かないために、戻り値の正規表現の各メソッドを呼べてしまう状態になっていた。
このバグはGecko 1.9.2(Firefox 3.6)以降ではすでに修正済みで、実際、Trunk等で戻り値の正規表現オブジェクトのメソッドを呼ぼうとすると、その場で処理が中断されて Error: RegExp.prototype.toString called on incompatible ChromeObjectWrapper というエラーがエラーコンソール上に出力される。
ということで、JavaScript/Migemo互換のAPIとして正規表現オブジェクトのソース文字列だけを返すような機能を0.12.2で新たに加えた。文字列や数値などのプリミティブ値に対してはセキュリティのチェックが行われないようなので、こっちはGecko 1.9.2以降でもWeb上で使える。