前回の記事では、新しいJavascriptエンジンについて説明しました Mozillaの人々は、70月の翌月に到着するFirefox XNUMXの次のバージョンに取り組んでいます（メモは、 次のリンク). この記事では、Mozillaによる発表についてお話します。 WebExtensionsAPIに基づくFirefoxアドオンの使用について Mozilla開発者が彼らの立場を公表した その中で 彼らは、Chromeアドオンマニフェストの次の第XNUMX版に完全に従うつもりはありません。
これにより、彼らは特に、 Firefoxは引き続きwebRequestAPIブロッキングモードをサポートします、これにより、受け入れられたコンテンツをその場で変更でき、広告ブロッカーやコンテンツフィルタリングシステムで需要があります。
WebExtensions APIへの移行の主なアイデアは、FirefoxとChromeのプラグイン開発テクノロジーの統合でした。したがって、現在の形式では、FirefoxはChromeマニフェストの現在の100番目のバージョンとほぼXNUMX％互換性があります。
マニフェストは、提供される機能とリソースのリストを定義します 補数のために。 lによって否定的に認識される制限措置の導入のための開発者 マニフェストの第XNUMXバージョンのプラグイン、 Mozillaはマニフェストに完全に従う慣行を放棄し、Firefoxに変更を転送しません プラグインの互換性に違反します。
すべての異議にもかかわらず、GoogleはWebRequest APIモードをブロックするモードでのChromeのサポートを終了し、読み取り専用モードのみに制限し、declarativeNetRequestAPIの新しい宣言型コンテンツフィルタリング機能を提供する予定であることを忘れないでください。
webRequest APIを使用して、ネットワークリクエストへのフルアクセスを備え、トラフィックをオンザフライで変更できる独自のコントローラーを接続できる場合、新しいdeclarativeNetRequest APIは、独立して処理する、すぐに使用できるユニバーサル組み込みフィルタリングエンジンへのアクセスを提供します。ブロッキングのルールは、独自のフィルタリングアルゴリズムの使用を許可せず、条件に基づいて複雑なルールを互いにオーバーラップさせることを許可しません。
Mozillaはまた、他のいくつかの変更をサポートするためにFirefoxに移植することの便利さを評価しています。 プラグインのサポートに違反するChromeマニフェストのXNUMX番目のバージョンから：
- La サービスワーカーの処刑への移行 バックグラウンドプロセスの形で必要になるのは、開発者がいくつかの追加のコードを変更することです。
新しい方法はパフォーマンスの点でより最適ですが、Mozillaはバックグラウンドページの実行のサポートを維持することを検討しています。 - 新しい詳細な権限リクエストモデル： プラグインはすべてのページですぐにアクティブ化することはできません（「all_urls」権限が削除されます）が、アクティブなタブのコンテキストでのみ機能します。つまり、ユーザーは各サイトでプラグインが機能することを確認する必要があります。 このセグメントでは、Mozillaは、ユーザーの気を散らすことなくアクセス制御を強化する方法を模索しています。
- クロスオリジンアプリケーション処理の変更： 新しいマニフェストによると、コンテンツ処理スクリプトには、これらのスクリプトが挿入されるメインページと同じ権限制限が適用されます（たとえば、ページにロケーションAPIへのアクセス権がない場合、スクリプトプラグインは取得しませんこのアクセスも）。 この変更はFirefoxで実装される予定です。
- 外部サーバーからダウンロードしたコードの実行の禁止 （プラグインが外部コードをロードして実行する状況について話しています）。 Firefoxはすでに外部コードブロッキングを使用しており、Mozilla開発者は、マニフェストのXNUMX番目のバージョンで提供される追加のコードダウンロード追跡技術を使用して、その保護を実施できます。