Mozilla 不會繼承新 Chrome 清單中的所有 WebExtensions API 限制

摩斯拉公司 宣布了，儘管 Firefox 使用了基於 WebExtensions API 的附加系統，但開發人員並不打算完全遵循未來第三版 Chrome 附加元件宣言。 特別是，Firefox 將繼續支援 API 的阻止模式。 網路請求，它允許您動態更改接收到的內容，並且是廣告攔截器和內容過濾系統所需要的。

轉向 WebExtensions API 的主要想法是統一 Firefox 和 Chrome 的附加元件開發技術，因此在目前的形式下，Firefox 幾乎 100% 相容於當前第二版 Chrome 清單。 清單定義了提供給附加元件的功能和資源清單。 由於第三版宣言中引入了限制性措施，附加組件開發人員對此持負面看法，Mozilla 將放棄完全遵循宣言的做法，並且不會將違反附加組件兼容性的更改轉移到 Firefox。昂斯。

回想一下， 儘管 上 所有 反對意見，Google打算停止支援Chrome中webRequest API的阻塞模式，將其限制為唯讀模式，並提供新的聲明式API用於內容過濾 聲明式網絡請求。 雖然 webRequest API 允許您連接自己的處理程序，這些處理程序可以完全訪問網絡請求並能夠動態修改流量，但新的 declarativeNetRequest API 提供對現成的通用內置過濾引擎的訪問，該引擎獨立處理阻止規則，不允許使用您自己的過濾演算法，也不允許您根據條件設定相互重疊的複雜規則。

Mozilla 也正在評估轉向 Firefox 支援的可行性，以應對第三版 Chrome 清單中的一些其他更改，這些更改破壞了與附加元件的兼容性：

• 過渡到以後台進程的形式執行 Service Worker，這將需要開發人員更改一些新增的程式碼。 儘管從效能角度來看，新方法更加高效，但 Mozilla 正在考慮維持對運行後台頁面的支援。
• 新的細化權限請求模型 - 此附加元件將無法一次為所有頁面啟動（「all_urls」權限已被刪除），但只能在活動標籤的上下文中工作，即使用者需要確認該附加元件適用於每個網站。 Mozilla 正在探索加強存取控製而又不斷分散用戶注意力的方法。
• 處理跨來源請求的變更 - 根據新的清單，內容處理腳本將受到與嵌入這些腳本的主頁相同的權限限制（例如，如果該頁面無權訪問location API，那麼腳本附加元件也不會收到此訪問權限）。 該更改計劃在 Firefox 中實施。
• 禁止執行從外部伺服器下載的程式碼（我們討論的是加載項載入並執行外部程式碼的情況）。 Firefox 已經使用了外部程式碼阻止，而 Mozilla 開發人員願意透過使用第三版清單中提供的附加程式碼下載追蹤技術來加強這種保護。

來源： opennet.ru