Webアプリケーションには小さなブラウザプラグインが必要な機能があります。アプリケーションの99％がASP.NET + javascriptであり、私たちはブラウザープラグインやそれを維持するための訓練への興味がないので、フリーランサーのWebサイトを使って大成功を収めて、動作中のFirefoxプラグインを入手しました/アドオン/拡張。firefoxプラグインを将来のリリースと互換性を持たせるにはどうすればいいですか
しかし、新しいFirefoxの新しいリリースでは、新しい拡張が必要なように見えるため、新しいFirefoxの迅速なリリーススケジュールではこの計画全体が混乱することになりました。これは、単にRDFファイルのem：maxVersionバージョンとは関係ありません。プラグインは実際に読み込みを拒否しているので、6週間ごとに次のバージョンのFirefoxのプラグインを更新するためにフリーランサーに委託する必要があります。私の限られた理解から、これは、geckoの各バージョンが前のバージョンと互換性がないためです。
ここで何か不足していると思います。例えば、IEプラグインはIE6のために約2005年に書かれたもので、私たちはそれに触れる必要は一度もありませんでした。 IE9でも動作します。すべてのFirefoxのプラグインを6週間ごとに書き直さなければならないのか、それとも間違っているのですか？
プラグインの基本機能は、ウィンドウ・タイマーを使用して共有メモリーをポーリングし、DOMをトラバースして特定のjavascript関数を持つページを検索して呼び出すことです。
私の質問は、より合理的な寿命（すなわち年以上）でFirefoxのプラグインを作成する方法があるのか、それとも新しいバージョンを毎回新しいものにする必要があるfirefoxの出てくる？
アドオンはバイナリコード（例：C++）を使用していますか？もしそうならば、Firefoxは各リリースとバイナリ互換性を壊すので、6週間ごとに再ビルドする必要があります。これを避ける方法は、JavaScriptを使用してアドオンを完全に書き込むことです。可能であれば、アドオンがMozillaのアドオンSDKによって提供される上位レベルのAPIを使用して完全に記述されるようにしてください。あなたのアドオンがSDKのapis内で動作できる場合は、互換性の問題を修正するためにアドオンを頻繁に更新する必要はありません。 – canuckistani
お返事ありがとうございます。現時点ではC++を使用しており、Windows共有メモリにアクセスする必要があるため、JavaScriptを使用することはできません。私に関係するもう1つの問題は、各Firefoxリリースで新しい拡張機能を発行しても、 Firefoxがアップデートする度にそれを再インストールする必要があります。これはFirefox製品チームに代わって自殺行動のようです。 – Andy
これの脚注として、私はちょうど（請負業者経由で）geckoとXPCOMではなくNPAPI（私が思う）を使って関数を再実装しました。同じDLLは3.6から10まで試したfirefoxのすべてのバージョンで動作し、またGoogle Chromeで（再パッケージ化されたとき）動作します。だから今私は満足しています – Andy