日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。データをメソッドの戻り値にする独自に開発したXPCOMコンポーネントに対して配列を渡したり、あるいは戻り値を配列で受け取ったり、ということをやる方法はいくつかある。上記エントリではコメント欄も含めると4つの方法が紹介されていて、そのうちコメント欄にある2つはJavaScriptの配列をそのまま受け渡せるという点で有用だ。nsIVariantインターフェースを使うやり方は、戻り値に使う時に余計な引数を定義しなくていいので、実際にそのXPCOMコンポーネントをJavaScriptから使う時にとても使い勝手がいい。いうことでXUL/Migemoでは積極的にnsIVariantを使ってたんだけど、これがMinefield(検証したバージョンは3.7a4pre)で動かなくなってた。結論から言うと、これはnsIVariantインターフェースのIIDが6c9eb060-8c6a-11d5-90f3-0010a4e73d9aから81e4c2de-acac-4ad6-901a-b5fb1b851a0dに変更されたせいで起こっている問題で、nsIDOMRangeのIIDが変更された時に起こった問題と同様の物だ。変更が入ったのは昨年9月で、HTML5の新しい仕様に対応するための作業の一環として、何らかの必要があってインターフェースに機能を加えると同時にIIDも変わったらしい。nsIVariantはFROZENなインターフェースじゃないから、nsIDOMRangeの時のようにIIDが元に戻されることは多分あり得ない。よって、考えられる対策は以下のいずれかということになる。APIをXPCOM経由で提供する事を諦める。2以前を切り捨てて、JavaScriptコードモジュールとして書き直す。3.7以降用とでXPIDLのコンパイル後のバイナリを分けて、Firefoxのバージョン別に2つのXPIファイルを提供するようにする。2で利用できなくなってしまう点と、APIが変わってしまう点。バイナリを分けるデメリットは、リリースの時の作業がめんどくさくなる(XPIファイルが2つになるので)という点。どっちを選んでも大変なのは変わらない......APIが変わってしまうことは避けたかったので、結局、後者の方で対処することにした。(xpidl)idlという感じにファイルを配置するようにした。いう風に複数のXPIを出力できるようになったので、リリースにかかる手間は少しは軽減された......のかな......追記。Gomitaさんのコメントを見て、IDLファイルからincludeの行を消して試してみたら、それでちゃんとコンパイルできた。なんでだ......!!!えーと。3.6まででも3.7以降でも問題なく使えるXPTファイルが作られるみたい。3.7以降でも使える。