Latest topics 近況報告

Firefox 3でコンテキストオブジェクトを明示して、日本語などを含むスクリプトを実行するための方法 - Jan 24, 2008

UxUのことで悩み中。

テストケースを実行するとき、コンテキストオブジェクトを指定してスクリプトを実行しないといけないんだけど、色々問題があって悩ましい。

brazilさんが紹介されているとおり、ビルトイン関数のevalに第2引数を渡すか、Objectクラスのメソッドであるevalを使うと、コンテキストオブジェクトを指定してスクリプトを実行することができる。ただ、この両者は若干動作が異なる。

例えばこんなコードを考えよう。

var context = {};
context.eval('var val1 = true; this.val2 = false');
alert(context.val1); // => true
alert(context.val2); // => undefined

Objectクラスのメソッドだと、実行したスクリプトの中で変数として宣言した物がそのままそのオブジェクトのプロパティとなり、外部から後で参照することができる。でも、

var context = {};
eval('var val1 = true; this.val2 = false', context);
alert(context.val1); // => undefined
alert(context.val2); // => undefined

ビルトイン関数の方だと、そうはならない。また、どちらにしてもthisを明示した場合は外部からは参照できない。

言い換えると、「コンテキストオブジェクトを明示して実行したスクリプトの中でvarで宣言された値を外部から取得するには、Objectクラスのevalメソッドを使わないといけない」ということ。

ところが、Firefox 3ではObjectクラスのevalメソッドが存在しない。どうやらどこかの時点で削除されてしまったようだ。

元のMozLabではどうしていたかというと、evalを使う代わりにmozISubScriptLoaderを使っていた。

var context = {};
var loader = Components.classes['@mozilla.org/moz/jssubscript-loader;1']
          .getService(Components.interfaces.mozIJSSubScriptLoader);
loader.loadSubScript(
  'data:application/x-javascript,'+encodeURIComponent('var val1 = true; this.val2 = false'),
  context
);
alert(context.val1); // => true
alert(context.val2); // => false

こちらは前二者のどっちとも結果が異なり、varで宣言した物もthisを明示した物も両方ともコンテキストオブジェクトのプロパティとして外部からアクセスできるようになる。

ところが。mozIJSSubScriptLoaderを使う方法だと、スクリプトの中に日本語などの非ASCII文字があると化けてしまう。

var script = 'alert("日本語")';　// Unicode

eval(script); // => "日本語"
({}).eval(script); // => "日本語"
loader.loadSubScript('data:application/x-javascript,'+encodeURIComponent(script), {}); // => 文字化けした文字列

encodeURIComponentによってUnicodeの文字列がUTF-8のバイト列に変換されてしまうのでこうなる、のか？　とにかく、これではテストケースの説明を日本語で書けなくて（僕が）困る。UxUではこの処理の直前でUTF-8なりShift_JISなりで書かれたテストケースを読み込んで内部コードのUnicodeに変換しているのだけれども、せっかく変換したのに最後の最後で化けてしまうんじゃあしょうがない。

ということでああでもないこうでもないと試していて、以下のような方法に辿り着いた。

var script = 'alert("日本語")';　// Unicode
script = 'eval('+script.toSource().replace(/^\(new String\(|\)\)$/g, '')+')';
loader.loadSubScript('data:application/x-javascript,'+encodeURIComponent(script), {}); // => "日本語"

encodeURIComponentに放り込む前に、一旦全体を文字列リテラルとして評価可能な文に変換して（この時点で日本語などの非ASCII文字は「\uXXXX」のようなUnicodeエスケープに変換される）、encodeURIComponentを通過した後でevalで元に戻す、というトンネル抜けのようなやり方。これによって、日本語で書かれた説明もそのまま利用できるようになった。

でも、これにもまだ問題がある。この方法で実行したスクリプトの中でエラーが起こると、MozUnitテストランナーのUI上でソースを表示してもeval("（元のテストケースのスクリプト）")という1行だけのソースになってしまって、エラー箇所がさっぱりわからない。これ、どうにかならんもんだろうか……

追記。エラーが発生した行の番号自体はこれでも正しく取れてるようなので、とりあえずやっつけ仕事で、MozUnitテストランナーのUI上でソースを表示する時にソースを元の文字列に復元するという方向で手を打とうと思う。

さらに追記。よく考えたら、わざわざ自分でソースを復元しなくても、変換前後で行数その他は変わってないんだから、ソース表示の時に元のファイルの方を読み込ませるようにしたらいいんだな……

さらにさらに追記。mozIJSSubScriptLoaderの仕様変更によってこの方法も使えなくなりました。現在何かいい手は無いか考え中。

さらにさらにさらに追記。上記内容と同じような結果になる代替案を考えてみた。

さらにさらにさらにさらに追記。evalの機能についてFirefox 3.1でまた変更があったようだ。

Firefox 3で安全にアドオンを配布するための方法のまとめ - Dec 25, 2007

第8回Mozilla拡張機能勉強会のプレゼン資料を公開した。

以下、内容を改めて整理してみる。

続きを表示する ...

XULRunnerアプリケーションにアドオンをインストールする方法 - Dec 17, 2007

McCoyの改造を試みるために、XULRunnerアプリでもアドオンを使えるのかどうかという実験をしてみた。

1. XULRunnerアプリを終了する。
2. インストールしたいアドオンのXPIパッケージの中にあるinstall.rdfを編集して、targetApplicationにそのXULRunnerアプリのIDを書き加える。ちなみにXULRunnerアプリのIDはアプリケーションのディレクトリにあるapplication.iniに書かれている。McCoyなら「mccoy@developer.mozilla.org」。
3. XULRunnerアプリのプロファイル内の「extensions」フォルダに、アドオンのXPIパッケージをコピーする。McCoyの場合は「C:\Documents and Settings\ユーザ名\Application Data\Mozilla\McCoy\Profiles\ランダムな文字列.default\extensions」。
4. XULRunnerアプリを起動する。
5. Firefoxの物と同じ「ソフトウェアインストール」のダイアログが表示されるので、「OK」ボタンを押してアドオンをインストールする。

これだけでいける。逆に、アドオンをアンインストールしたい時は、アドオンのID名が付いたフォルダをプロファイル内の「extensions」フォルダから削除する。

amachangさんはアプリやアドオンそのものの中身をガリガリ書き換えるやり方を紹介されてるけど、僕はこういうやり方はしない方がいいと思ってる。理由は以下の通り。

• アプリやアドオンが自動アップデートされる度に、その都度ソースを書き換え直さないといけない。Firefoxの場合特に設定を変えていなければ勝手にそれらが行われてしまうので、「気がついたら変更が失われてた」ということになりかねない。
• アプリやアドオンの自動アップデートを止めればその心配はなくなるが、今度は、セキュリティアップデートが適用されないので危険なままの状態が続いてしまうという別の問題が発生する。少なくとも僕については、ものぐさなので、毎回必ずコードを書き換え直すのを嫌ってセキュリティホールがあると知りながら古いバージョンの改造版を使い続けてしまいそう。

なので、これらの問題を回避するために、teramakoさんのようにそれ用のアドオンを作って使うか、userChrome.jsを使うかする方がいいと僕は思う。今回McCoy用の改造をアドオンという手法で行うことを試みているのも、そういう理由からだ。

落ちる - Dec 10, 2007

とよく言われるんだけど自分の環境＆自分の見てる範囲のWebサイトでは落ちないので原因が分からない、ということが多い。落ちるか落ちないかのギリギリの所をうまく突くようなコードを知らず知らずのうちに書いてしまっているのでしょうか。そんな能力いらなさすぎる。

APIを作る時はどんな使われ方をするかちゃんと考えてから作ろうという話 - Nov 30, 2007

ツリー型タブでずっと前から発生条件が分からなくて困ってた「一つもタブが選択されていない状態」になってしまうバグの原因がやっと分かったので、速攻で修正した。

この問題は、以下の条件がすべて揃った時に発生していた。

• タブバーの末尾に、ツリー状になったタブがある
• そのツリーが折り畳まれた状態で、ツリーの最上位の親のタブが選択されている
• そのタブを閉じる操作を行う

この時、内部的にどういう処理が行われていたかというと、以下のような感じだ。

1. removeTabメソッドが呼ばれる
2. removeTabメソッドにてTabCloseイベントが発生
3. TreeStyleTabBrowserのインスタンスがTabCloseイベントを捕捉
4. 1で閉じられようとしているタブがツリーの親で且つ子孫タブが折り畳まれている場合、TreeStyleTabBrowserが子孫タブを先に閉じる
5. TreeStyleTabBrowserのTabCloseイベントに対する処理が完了
6. removeTabメソッドの残りの部分に制御が戻る
7. 閉じようとしているタブが、選択されたタブだった場合、次に選択するべきタブを決定し、そのタブを選択する
8. removeTabメソッドの処理が完了

この「TabCloseイベント」というのがFirefox 2以降で使えるAPIなんだけれども、問題は7のステップで起こっていた。7のステップで「次に選択するべきタブ」を決定するためのキーとして「現在開いているタブの総数」を使っているのだけれども、その値は1のステップの間に取得しているため、1から7までの間のどこかでタブの数が増減した場合、タブの選択状態が狂ってしまうのである。7のステップで「現在のタブまたはそれよりあとのタブ」が選択される場合、ここでは4のステップでタブの数が減少しているため、「次に選択するタブの番号」が「すでに削除されたタブ」のインデックスを指し示すことになり、selectedTabの値がundefinedとなりNull Pointer Errorが発生してしまう。……というのが事の真相だった。

ツリー型タブの側でselectedTabのセッタを上書きし、もし存在しないタブが選択されそうになった時は強制的に最後のタブを選択するようにしたところ、「一つもタブが選択されていない状態」は発生しなくなった。以下はそのためのコード。

// var b = gBrowser

var getter = b.__lookupGetter__('selectedTab');
var setter = b.__lookupSetter__('selectedTab');
eval('setter = '+setter.toSource().replace(
    '{',
    '{ if (!val) val = this.mTabContainer.lastChild;'
));
b.__defineGetter__('selectedTab', getter);
b.__defineSetter__('selectedTab', setter);

この部分ではなく、removeTabメソッドを上書きするという手もあるんだけど、ここはいろんなアドオンが上書きしたがるためコンフリクトの原因になると思ったので、「標準的な動作と変わってしまう」ことは仕方がないと割り切って、ほとんど誰も触らないであろうselectedTabの方を上書きするようにした。ちなみに、ゲッタとセッタ両方を定義し直しているのは、片方だけを再定義するともう片方が未定義になってしまうから。

表題の件に流れを戻すと、「タブを閉じる」という操作をイベントとして捕捉できるようにしたのなら、そのイベントをトリガーにして他のタブを連動して操作するという機能も当然登場してくるわけで、そういうことを考慮せずに「はいはいイベント発行すりゃいいんだろdispatchEvent っと！」と適当に設計してしまうとこういうトラブルが起こるので、APIを作る時にはもうちょっと慎重になった方がいいよね、という教訓を得たという話なのでした。

ツリー型タブのAPI（他のアドオンから「子タブ」を開く方法） - Oct 22, 2007

ツリー型タブのAPIと称して3つのメソッドの使い方を公開しました。以下のようにして使ってください。

// 一つだけタブを開く場合
if ('TreeStyleTabService' in window)
  TreeStyleTabService.readyToOpenChildTab(gBrowser.selectedTab);
gBrowser.addTab('http://www.example.jp/');

// 複数のタブを開く場合
if ('TreeStyleTabService' in window)
  TreeStyleTabService.readyToOpenChildTab(gBrowser.selectedTab, true);
gBrowser.addTab('http://www.example.jp/');
gBrowser.addTab('http://www.example.com/');
gBrowser.addTab('http://www.google.co.jp/');
if ('TreeStyleTabService' in window)
  TreeStyleTabService.stopToOpenChildTab(gBrowser.selectedTab);

アドオンとかユーザースクリプトとかで、現在のタブに関連した情報を新規タブで開くような機能を持ってる物は、これを入れておくとユーザ（主に僕）が幸せになれると思います！

XULのtoolbarbuttonとCSSのopacityとpositionで嵌った - Oct 12, 2007

昨日XULとCSSであれこれ頑張ってみていて浮き彫りになってきた、XULとCSSのバッドノウハウの話の続き。

前のエントリで書いたことを踏まえて、toolbarbuttonの中のlabelを、XBLとstackを使って影付きテキストに置換するということをやってみたんだけど、そうすると今度は、ボタンを押しても何も反応しなくなってしまったじゃあないですか。こりゃ大変だ。

よーく観察してみると、ボタンのラベル文字列の部分はクリックしても無反応（ボタンの外観はちゃんと「押した」風になるんだけど、commandイベントが発行されない。コードを色々書き換えてみたけど、clickイベントすら発行されなかった。）だけど、それ以外の部分――ボタンの枠線とラベル文字列の間の余白部分あたりをクリックすると、ちゃんとボタンを押したものと認識される、ということに気がついた。ということはやっぱり、stackを使って影付きテキストにしたlabel要素が癌だってことだ。

んで条件を変えつつ色々試してみたら、以下のことが分かった。

• 半透明にしたlabel要素をクリックしても、親のボタンをクリックしたとは見なされない。
• 半透明じゃなくても、positionがstatic以外になっているlabel要素は、クリックしても、親のボタンをクリックしたとは見なされない。

言い換えると、「完全に不透明で、且つ、positionがstaticであるlabel要素」をクリックした時にだけ、そのtoolbarbuttonがクリックされたものとして正しく認識されるようだ、ということ。

というわけで苦肉の策として、ボタン上にポインタが乗っている時（:hover状態）はpositionもopacityも初期値（staticで不透明）にする、という風にしてみたところ、やっとちゃんとボタンをクリックできるようになってくれた。positionがstaticということはz-indexでの重ね合わせ順の制御が効かなくなるんだけど、影の方のopacityが1になればstackの原則通り内容は文書中の登場順に描画されるようになるので、トータルでは問題なくなる。:hoverの時だけ影が濃くなる（不透明になる）のは、まぁ、:hover時の特別なハイライト表示にも見えるので、結果オーライと言えよう。

ちなみに、この問題はtoolbarbutton要素だけでなく、menubar要素直下のmenu要素内にあるlabelについても起こる。こちらについても同じような対策で行けるかと思って、事実ほとんどの所はそれで良かったんだけど、:hoverの時だけということにしておくと、展開されたメニューを選択した後に再びmenuの部分にポインタを載せた時に、positionとopacityのリセット用指定が反映されないという現象が起こってしまったので、代わりに[_moz-menuactive="true"]という具合に内部処理用の属性を使ってみることにした。

そんな感じで、現行Geckoにはこういういやーなバグがまだまだ潜んでいて、案外苦労してしまうことが少なくない。そこら辺が改善された新しいバージョンっていつ出るのかなあ……

XULのstackとCSSのopacityで嵌った - Oct 12, 2007

昨日XULとCSSであれこれ頑張ってみていて浮き彫りになってきた、XULとCSSのバッドノウハウいくつか。

1. XULのstackとCSSのopacityの微妙な関係について
2. XULのtoolbarbuttonとCSSのopacityとpositionの微妙な関係について

まず一つ目。一般的なWebページ制作では、要素同士を重ね合わせるにはCSSのポジショニングを使うのが一般的で、XULでも同じ方法を使えるんだけど、もう一つの方法として、XULにはstackという要素がある。

通常、XULではhbox（内容が横に並ぶボックス）またはvbox（内容が縦に並ぶボックス）の2つのボックスをコンテナとして使い、縦横二方向のボックスの並びだけでGUIを作る、というのが原則となっている。この原則を覆すのがstackというコンテナ要素だ。多くのXULのコンテナ要素においては、内容に含めた要素のボックスが縦または横に並ぶのに対し、stackは、内容に含めた要素のボックスが同じ座標に重ねて表示される、という特徴がある。

チュートリアルではこれを使って影付き文字を作る例を示しているけれども、これを見て当然思いつくのが、影を半透明にして背景に自然に馴染ませたいという要求だろう。

<stack>
  <description value="Shadowed"
               style="color: black; opacity: 0.5;"
               top="1" left="1"/>
  <description value="Shadowed"
               style="color: white;"/>
</stack>

ところが、この例は実際には意図通りに表示されてくれない。Geckoのバグだと思うけど、stackの中に一つでも半透明の要素があると、stack全体が半透明になってしまうのである。つまり、ここでは影だけを半透明にしたいのに、実際には前景の文字まで半透明になってしまって却って字が読みにくくなる。

で、色々試してみた結果、stackを二重にするとこの問題を回避できるっぽい、という事が分かった。

<stack>
  <stack>
    <description value="Shadowed"
                 style="color: black; opacity: 0.5;"
                 top="1" left="1"/>
  </stack>
  <description value="Shadowed"
               style="color: white;"/>
</stack>

こうすると、内側のstackは全体が半透明になってしまうけど、外側のstackにはその影響は及ばないので、影だけを半透明にできる。（ここでは影のテキストが一つだけしかないけど、実際にはText Shadowと同様の方法で複数の薄い影をずらしながら重ねたかったということなので、stackを二重にしている。）

ただ、今度は入れ替わりに、要素の重ね合わせの順番がおかしくなるという問題が起こってしまった。XULのstackは先に入っている要素ほど下に、後に入っている要素ほど上に描画されるはずなんだけど、どういうわけか、半透明にした要素は不透明の要素よりも上に強制的に描画されてしまうようだ。

（……と思ってたんだけどもしかしたらこれは勘違いかもしれない。stack内の要素はtop属性とleft属性で場所を動かせるんだけど、もしかしたら、これらの属性がある場合は強制的にその要素がposition: relativeにされてしまって、通常のposition: staticな要素の上に表示されるようになってしまった、ということだけなのかも……これはまだ検証してない。）

そこでさらに、z-indexを使って重ね合わせの順番を指定してみたところ、やっと「半透明の影の上に不透明の文字を重ねる」という結果を得ることができた。

<stack>
  <stack style="position: relative; z-index: 1;">
    <description value="Shadowed"
                 style="color: black; opacity: 0.5;"
                 top="1" left="1"/>
  </stack>
  <description value="Shadowed"
               style="color: white; position: relative; z-index: 2;"/>
</stack>

position: relative を指定しておかないとz-indexの指定が効かない(z-indexはpositionがstatic以外の要素にしか効果がない）ので、それもセットで指定してある。

これでやっと問題を解決できたか、と思ってたんだけど、あろう事か今度はまたさらに別の問題にぶち当たってしまった。というところで、話は次のエントリへ続きます。

XPIの生成とハッシュ値の取得とRSSの生成の自動化 - Oct 10, 2007

XPIパッケージ生成用のバッチファイルとかシェルスクリプトとかを更新した。

• プラットフォームごとのファイルを含めた拡張機能に対応。
• 調べてみたらLinuxとCygwinには最初からファイルのSHA-1ハッシュを取得するsha1sumというコマンドがあったので、それを使って、XPIパッケージの生成時に同時にSHA-1ハッシュも出力するようにした。
• Split BrowserのページなどのHTMLからRSSを自動的に生成（更新）する秀丸マクロについて、SHA-1ハッシュの値も取り込むように改良して、リポジトリに追加した。
• sedを使って、Mozilla Add-ons用のXPI（updateURLとupdateKeyをinstall.rdfから削除した物）も同時に生成するようにした。

Windows用のバッチファイルはCygwinにおもくそ依存してます。Bash用シェルスクリプトは最初の行のパスさえ直せば多分他の環境でも普通に使えると思う（Ubuntu 6.06ではそのまま動いてる）。使い方は前に書いた解説を参照してください。

秀丸マクロ（Sync.mac、xul_updates.mac、xul_updates2.mac）はいずれもパスやファイルの構成を決め打ちで作ってるんで汎用性はないけど、まあ、似たようなことをやりたい人の参考になれば幸いです。（この辺もそのうちもっと汎用的なバッチファイルなりシェルスクリプトなりに置き換えたいんだけど……）

sedの使い方が少し分かってきたので、もうちょっと複雑なことができるようになりそう……かも？

Chromeウィンドウを最前面にする・最背面にする - Sep 26, 2007

Chromeウィンドウでは、window.open()やwindow.openDialog()の第3引数でalwaysRaisedフラグを指定することで、「常に最前面に表示」状態のウィンドウを開くことができる（通常のスクリプトではこのフラグを使うには特権が必要）。じゃあ、すでに開かれているウィンドウを最前面にすることはできないのか？　というのが今日のお題。

フォクすけクロックを使ってみて、Firefoxのウィンドウの下に時計が隠れてしまうのは不便きわまりないと思ったので、これをどうにかしたかった。最初は、前述のalwaysRaisedを使った方法でいけるかなと思ったんだけど、Firefoxのアドオンとして動作する時はこれでいいけどXULRunnerアプリとして動作する時には「開く元の親ウィンドウ」が無いからこれじゃダメだ、と気がついた。

んでちょっと調べてみた所によると、どうもnsIXULWindowインターフェースのzLevelというプロパティをいじることで、ウィンドウの重ね合わせの優先順位を動的に変更できるようだということが分かってきた。

以下のようにいくつかのインターフェースを経由することで、Chromeウィンドウ（nsIDOMWindow）からnsIXULWindowのインターフェースに辿り着くことができる。

var Ci = Components.interfaces;
var XULWindow = window
    .QueryInterface(Ci.nsIInterfaceRequestor)
    .getInterface(Ci.nsIWebNavigation)
    .QueryInterface(Ci.nsIDocShellTreeItem)
    .treeOwner
    .QueryInterface(Ci.nsIInterfaceRequestor)
    .getInterface(Ci.nsIXULWindow);

XULWindow.zLevel = Ci.nsIXULWindow.raisedZ;

zLevelに指定可能な値はnsIXULWindowインターフェースにおいて定数プロパティとして定義されていて、以下の種類がある。

プロパティ	実際の値	意味
Ci.nsIXULWindow.lowestZ	0	すべてのウィンドウの最背面
Ci.nsIXULWindow.loweredZ	4	すべてのChromeウィンドウの最背面
Ci.nsIXULWindow.normalZ	5	通常
Ci.nsIXULWindow.raisedZ	6	すべてのChromeウィンドウの最前面
Ci.nsIXULWindow.highestZ	9	すべてのウィンドウの最前面

lowestZとloweredZの違いは、前者がエクスプローラその他Windowsネイティブのアプリケーションのウィンドウも含めてすべての最背面になるのに対して、後者はあくまでFirefoxのウィンドウの中での最背面になるだけであるということ。loweredZを指定したChromeウィンドウが他のネイティブアプリのウィンドウの下にある時、そのChromeウィンドウをクリックすると、そのChromeウィンドウがネイティブアプリのウィンドウの上に表示されるようになると同時に、それに「押し上げられる」形で、FirefoxのウィンドウすべてがそのChromeウィンドウより前面に表示される。

highestZとraisedZもそれと同様に、後者を指定したウィンドウは上にネイティブアプリのウィンドウが重なりうるけど、前者にはいかなるウィンドウも上には重ならない……のかと思いきや、こちらはどっちを指定してみてもraisedZで期待される通りの挙動にしかならなかった（Firefoxのウィンドウの中での最前面になるだけで、他のネイティブアプリのウィンドウが前面にくると、その下に隠れてしまう）。これってバグ？

ちなみに、数値で1～3を指定した場合はloweredZ（4）を指定したのと同じ挙動になるようだ。多分7～8はraisedZ（6）と同じで、それ以上はすべてhighestZ（9）と同じになるんだろうと思うけど……前述の通りhighestZとraisedZは実際の挙動に違いが全然無いので、それを確認することはできなかった。

あと、ずっと前にEz Sidebarでこの問題にぶち当たってから気になってるもののずっと直ってないみたいなんだけど、raisedZ以上が指定されたウィンドウがあると、通常のウィンドウで開いたモーダルダイアログが親ウィンドウの下に潜ってしまうという問題が起こる。パスワードの入力を求めるダイアログ等がFirefoxのウィンドウの下に潜ってしまって使い物にならないので、これはマジで困る。どうにかならんものだろうか。

――ということで対策を考えてみた。

var XULWindow = window
     .QueryInterface(Ci.nsIInterfaceRequestor)
     .getInterface(Ci.nsIWebNavigation)
     .QueryInterface(Ci.nsIDocShellTreeItem)
     .treeOwner
     .QueryInterface(Ci.nsIInterfaceRequestor)
     .getInterface(Ci.nsIXULWindow);
var observer = {
  observe : function(aSubect, aTopic, aData)
  {
    if (aTopic == "xul-window-registered") {
      XULWindow.zLevel = Ci.nsIXULWindow.normalZ;
      window.setTimeout(function() {
        XULWindow.zLevel = Ci.nsIXULWindow.highestZ;
      }, 250);
    }
  }
};

var ObserverService = Cc["@mozilla.org/observer-service;1"]
      .getService(Ci.nsIObserverService);
ObserverService.addObserver(MakeOnTopObserver,
                            "xul-window-registered", false);

新しいウィンドウが開かれる直前にウィンドウのzLevelを元に戻して、ウィンドウが開かれた後にまた最前面に戻す。こうすれば最後の問題は回避できる。