nsIURIFixupFirefoxアドオンを介して、Firefoxのデフォルトの実装をオーバーライドしようとしています。このサービスは一度作成され、 の構築後にグローバルにキャッシュされるためnsDocShell、docshell が初期化される前にコンポーネントを登録する必要があります。したがって、コンポーネントをできるだけ早くロードするためchrome.manifestのカテゴリを含め、(JS) XPCOM コンポーネントを登録するために使用します。profile-after-change
これは単一プロセスの Firefox (37) ではうまく機能しますが、Electrolysis (e10s) が有効になっている場合 (Firefox Nightly など) には機能しません。chrome.manifestこの問題は、アドオンが Firefox のブラウザー プロセスにのみインポートされ、e10s がアクティブ化されたときにそのコンテンツ プロセスにインポートされないという事実によって引き起こされます (バグ 596880、WontFix としてマークされています)。
のメソッドを呼び出すフレーム スクリプトで JSM をインポートすることにより、コンテンツ プロセスにコンポーネントを動的に登録できます。これはおそらくほとんどのアプリケーションで機能しますが、docshell が構築される前にコンポーネントを初期化する必要があり、フレーム スクリプトのロードが遅すぎるように見えるため (つまり、docshell が既に構築されている場合)、私の場合はそうではありません。registerFactorynsIComponentRegistrar
また、インターフェイスの (間接的な) コンシューマーを追跡してモンキー パッチを適用するなど、機能を実装する他の方法も検討しました。この壊れやすい「ソリューション」は嫌いです。ドキュメント化されていない実装の詳細に依存しているため、将来いつでも壊れる可能性があるからです。
コンポーネントを Firefox の global に追加できることも思いつきましたchrome.manifestが、これもひどいハックのように思えます (たとえば、管理者によってインストールされたために、このファイルが読み取り専用である場合はどうなるでしょうか? そして、AMO がインストールの一部として Firefox のコア ファイルの 1 つを変更するアドオンを受け入れます...?)。
では、コンテンツ プロセスが作成されるとすぐに読み込まれるコンポーネントを適切に登録して、そのプロセス内のインターフェイスの実装を効果的にオーバーライドできるようにするにはどうすればよいでしょうか?