XPConnect wrappers – MDC てきとう和訳

どこかでXPCSafeJSObjectWrapperというのを目にして、なんだそれと思ってしらべたらFirefox3からXPCCrossOriginWrapperというのもできたとXPConnect wrappers – MDCに書いてあったのでてきとうな和訳をしました。そういうのがあるっていうのはわかったけど、どこで使われてるのか、どう使うのか、さっぱりわかりません。XPCCrossOriginWrapperはソース検索しても実装とテスト以外出てこないし。

Base Wrappers

XPCWrappedNative

C++実装のオブジェクトをjsに反映reflectするときに生成されるもの。
DOMオブジェクト(windowとか)やchrome要素がこれ。

jsからの呼び出しをC++にマッピングをやってくれる。window.focus()を呼ぶとXPCWrappedNativeのコードを呼んでいることになる。

このラッパはimplicitにXPConnectが生成するので気にしなくていい。
XPCWrappedNative には何種類かあるけどここではとりあげない。

XPCWrappedJS

XPCWrappedNativeと逆のことをするラッパ。
js実装のオブジェクトをC++から呼び出すときに使われる。

XPConnectによって生成されるので気にしなくていい。

Wrapper Wrappers

ここから難しくなってくる。まえの二つはひとつのC++もしくはjsのオブジェクトをラップしてそれをreflectしてるだけだった(厳密には正しくない。下のdouble-wrappingをみてね)。
以下のラッパはほかのjsオブジェクトをラップして、いろんなことをやってくれる。

XPCNativeWrapper

このラッパは初めて作られたラッパーラッパだ。XPCNativeWrapperはXPCWrappedNativeをラップしてるだけで、そのほかのjsオブジェクトをラップしようとすると例外を投げる(このことについて詳しくはdouble-wrappingのところをみてね)。

XPCNativeWrappersはjsのdynamicismからユーザを保護するためにデザインされています。
例を挙げると、

someAnchor.href="http://www.mozilla.com"

っていうコードは、someAnchorが呼ばれたときに悪意あるコードを実行して、正しく動かないようにできます(超訳注: someAnchorのhrefにgetterを設定しておいて無効なhrefを返したりするとかする)。someAnchorがXPCNativeWrapperでラップされていればこれは起こりません。ラッパーは常にIDL(or convention in the case of DOM0 behavior)で定義されたオリジナルのアクションを実行するからです。

XPCNativeWrappersはchromeのjsやchromeのcomponentがcontent(less privileged)(超訳注: ふつうのブラウザのウインドウで表示されるページの中身。chromeからはwindow.contentでアクセスできるのでcontentとして表現されている)オブジェクトにアクセスするときはいつもimplicitに生成されます。They can also be created by using new XPCNativeWrapper(wrappedNative) を使うことで生成することもできます。IDLでは定義されていない”Expando”プロパティは、ラップされたオブジェクトによって作られて、ラッパを介しては見えません。

このトピックについて詳しくはXPCNativeWrapperとSafely accessing content DOM from chromeをみてください。

XPCSafeJSObjectWrapper

New in Firefox 3
このラッパはXPCNativeWrapperのいくつかの問題に対処するために作られました。特に、extensionによってはネイティブで実装されていないcontentで定義されたオブジェクトに安全にアクセスしたいことがあります(超訳注: gmailの拡張やLDRの拡張のように、contentが定義する変数を呼び出せば楽に何かができる場合など)。XPCSJOWはchromeコードとのバッファとして機能します。

Note: あらかじめ定義された動作を持たない、どんな種類のオブジェクトもラップできるので、ここで保証されるのは信頼できないコードは信頼できないコンテキストでしか実行されないということだけです。In particular, the underlying object might act entirely differently from what is expected.(超訳注:わからん)

Safe JSObject wrappers はいくつかの状況ではimplicitに生成されます。全てのプロパティをラッパ越しにみることができます。

XPCCrossOriginWrapper

New in Firefox 3
cross origin wrapper(XOW)はサイト間のアクセスを仲介するために実装されました。このラッパはXPConnectによってimplicitに生成されます。XOWのコードの中ではすべてのアクセスがチェックされます。
コードを実行するときに同じオリジンのオブジェクトをラップするときは、ラッパはSafe JSObject wrapperとして働き、JSオブジェクトにできることならなんでもXOW経由ででもできます。
ラップしたオブジェクトがアクセスできないときは(超訳注:おそらくオリジンが違ってアクセスできないとき、という意味)XPCNativeWrapperのように働きます。つまり、サイトがAPIをオーバーライドしていてもIDLで動作が規定されているAPIにのみアクセス可能です。

で、どれつかったらいいの?

オーケー、ざっと見たところでコード書きたいよねー。どのラッパを使ったらいいかな。

Chrome Code (extensionとか)

XPCNativeWrapperをみてね。

もっとオブジェクトにアクセスしたいとかcontentがjsで定義したオブジェクトとかIDLにないものにアクセスしたいときはXPCSafeJSObjectWrappersを使いましょう。Firefox3からはXPCNativeWrapper.wrappedJSObjectからimplicitに得ることもできるし、明示的にnew XPCSafeJSObjectWrapper(object)って書いてももいいです。

Note, however, that I’m (mrbkap) looking into implicitly creating these wrappers in all relevant cases and removing the visible constructor.(超訳注:わからん) Firefox2以前だとcontentの定義したjsオブジェクトに安全にアクセスする方法はないです。

Content Code (a webpage)

いままでそうだったのとおなじように、contenのコードはラッパーとかラップとか気にしなくていいです。特にXOWができたのでブラウザが規定してるセキュリティ制約に従っていればラッパのことは気にしなくていいです。でもこれはセキュリティのことを無視していいとかXOWが安全ベルトだと思っていいってことじゃないよ。守ってくれはするけど事故につながることはやっぱりあるよ。

Details

double wrappingのことについて触れたので、それについてもう一度。dobule wrappingはXPCWrappedNativeが他のオブジェクトをラップしてるときのことで、つまりJSオブジェクトがIDLで宣言されているインターフェイス経由で渡されて、XPCWrappedJSが生成されて、javascriptに他のインターフェイス経由で返されたときのことだけど、APIの互換性を保つためにXPCWrappedNativeがXPCWrappedJSのまわりに作られますよ。