プラグインを開発しており、特定のホストのブラウザ プロキシを取得する必要があります。
現在、nsIProtocolProxyServiceを使用して動作します。ただし、NewURI関数 ( nsIProtocolProxyService::resolve() で使用される URI オブジェクトの構築に必要 ) は、 nsACStringへの const 参照を 取ります。そして、それを具体的に実装するには、xpcomglueとリンクする必要がありますが、これはできません(正しく理解している場合、技術的な理由で動的にリンクするべきではありません;法的な理由で xpcomglue_s と静的にリンクすることはできません)。 .
では、 xpcomglue とリンクせずにブラウザ プロキシを取得するにはどうすればよいでしょうか。
これは間違いなくトリッキーな質問です。実際、(可能な場合) 最善の方法は、可能であれば NPN_GetURL/NPN_PostURL スタイルの NPAPI 関数を使用することです。それが不可能な場合は、最新のブラウザー バージョンに頼れない限り、多かれ少なかれ窮地に立たされていることになります。
Firefox / gecko API の最近のバージョンを想定できる場合 (Firefox 3.6 がこれをサポートしていると確信していますが、どちらが開始されたかは定かではありません。ドキュメントには gecko SDK 1.9 と書かれていますが、その時点では存在していなかったと思います)。NPNURLVProxyで NPN_GetValueForURL を使用して、特定の URL のプロキシ情報を取得できます。
繰り返しますが、これは新しいブラウザーでのみ機能することを覚えておいてください。また、これをサポートするものについて互換性マトリックスをコンパイルする機会がまだありませんでした。これをFireBreathに追加する計画がありますが、1.4 には含まれていないため、追加されるまでにはさらに 1 か月かかる可能性があります。
フェールオーバー オプションとして、これが利用できない場合の最も一般的な解決策は、単に WinInet (インターネット エクスプローラー) のプロキシ構成を取得し、それが同じであることを信頼することです。
これは (IMO) 重大な問題であり、本当に適切な修正はありません。これが、プロキシを介したネットワーク アクセスでも Flash が気まぐれであることで有名な理由です。
XPCOM を使用する NPAPI プラグインを開発するべきではありません。Mozilla のドキュメントを参照してください。おそらく、やろうとしていることの少なくとも一部に Firefox 拡張機能を使用し、それとプラグインの間で JS バインディングを使用して通信することができます。