Home > Latest topics

Latest topics > あ、やっとSplitWindowの意味が分かった

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

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

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

あ、やっとSplitWindowの意味が分かった - Sep 13, 2005

SplitWindowというのが一体どういうものなのか今の今までとんと理解できなかったんだけど、やっと分かった。ソースをタブで表示するのに引数オブジェクトを渡せない問題、これこそがSplitWindowの影響だったんだな。

つまりSplitWindowというのは、一つのページのビューが二つの名前空間を持っていて、関数の実行コンテキストによって、参照される名前空間が変わるというものなんだ。

以下、実例。

具体的にはこういう事だ。まず、以下のような内容のページをブラウザ内で読み込んだとする。


<!-- XML宣言、DOCTYPE宣言は省略 -->
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>test</title>
  </head>
  <body>
    <script type="application/javascript"><![CDATA[
      window.testNumber = 10;
    ]]></script>
    <p><button onclick="alert(window.testNumber);">click</button></p>
  </body>
</html>

次に、ブラウザウィンドウ(chrome://browser/content/browser.xul)のコンテキストで以下の関数を実行する。


gBrowser.contentWindow.testNumber = 50;
alert(gBrowser.contentWindow.testNumber);

今までであれば、内容ウィンドウの実行コンテキストのwindowとブラウザウィンドウのgBrowser.contentWindowは同じ物を指していた。つまり、この状態で、読み込んだページのclickと書かれたボタンをクリックすれば、50と表示される。

ところがSplitWindow実装後のGeckoでは、実行コンテキストによってwindowオブジェクトの名前空間、プロパティを保持するメモリ領域が切り替わる。そのため、ブラウザウィンドウのコンテキストで実行したスクリプトではgBrowser.contentWindow.testNumber50と表示されるのに、ページ内のボタンをクリックすると、相変わらず10と表示される。「ブラウザウィンドウの実行コンテキストにおけるtestNumberプロパティ」と「内容ウィンドウの実行コンテキストにおけるtestNumberプロパティは、それぞれ全く別個のものとして扱われるんだ。

この名前空間のスイッチングは、windowオブジェクトだけでなく、それに従属している全てのオブジェクトに対して行われる。だから、ブラウザウィンドウの実行コンテキストでcreateElement()で生成した要素ノードに新たなプロパティを付与した上で、内容ウィンドウのDOMツリーにappendChild()等で埋め込んでも、内容ウィンドウの実行コンテキストになった瞬間に名前空間が切り替わるので、要素ノードに付与したプロパティは、内容ウィンドウの実行コンテキストからは完全に不可視になる。

ちなみに、gBrowser.contentWindow.setTimeout("expression", timeout)といった形でタイマー処理させた場合は、文字列として渡したexpression部分は内容ウィンドウの実行コンテキストで実行されることになる。また、ドキュメントのDOMツリーの変更(要素の属性のセットや内容の追加・削除など)は実行コンテキストに関係なく反映されるようだ。そのため、単純な文字列や数値などであれば、ブラウザウィンドウから内容ウィンドウへと受け渡しできる。

……ということで、分かってみれば「なーんだそういうことか」という話だった。こりゃあ確かに強力だ。これによって、「ブラウザウィンドウの実行コンテキストで内容ウィンドウの中にChromeウィンドウ内の関数や変数への参照を作っていたら、内容ウィンドウの実行コンテキストでそれらにアクセスされ、情報漏洩や攻撃の糸口に利用されてしまう」という危険はなくなったと考えていい。

セキュリティ的には非常に嬉しい進歩なんだけど、それが今回の問題では仇になってしまってるんだな。名前空間が異なってしまっているために、選択範囲オブジェクトや元ウィンドウのwindowオブジェクトなんかの、JavaScriptオブジェクトそのものは、どう頑張っても渡すことができない。いやーもう完全にお手上げですわ。

分類:Mozilla > XUL, , , 時刻:02:09 | Comments/Trackbacks (3) | Edit

Comments/Trackbacks

いまいち理解しきれてないんですけど

イマイチ理解しきれていないので外してたらごめんなさい。

いかにコンテンツ部分と、chrome部分とでメモリ空間が違おうとも、chrome部分からコンテンツ部分のオブジェクトを取得できれば問題無いんじゃないかという話に落ち着くと思います。

現在、Firefox(Trunk/1.8branch)のFAYTはXPCOMを通して発見したリンクの要素を取得して、これに疑似フォーカスを与えるために見た目を操作したり、イベントの発行を行ったりしています。(ちゃんと動いてます)

つまり、別の手段でコンテンツのwindowオブジェクト等を取得する方法が何かあるんじゃないんでしょうか?

とりあえずFAYTのソースはこちらを。
http://lxr.mozilla.org/mozilla/source/toolkit/components/typeaheadfind/content/findBar.js

Commented by 中野雅之 at 2005/09/13 (Tue) 02:35:44

no title

とりあえず、viewSource.xulやviewPartialSource.xulの初期化処理の一部を自力で行うことで解決を図ることにしました。

ああめんどくさ……

Commented by Piro at 2005/09/13 (Tue) 03:51:07

XPCNativeWrapper

自分もよくわかっていませんが、
xpcnativewrappers=no で、
gBrowser.contentWindow.testNumber にアクセスできました。

https://bugzilla.mozilla.org/show_bug.cgi?id=302276
http://developer.mozilla.org/en/docs/Safely_accessing_content_DOM_from_chrome

Commented by fls at 2005/09/13 (Tue) 06:25:49

TrackBack ping me at


の末尾に2014年1月19日時点の日本の首相のファミリーネーム(ローマ字で回答)を繋げて下さい。例えば「noda」なら、「2005-09-13_splitwindow.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 ブラウザ無料ダウンロード