Mozilla的 最近宣布 打算使 您的网页浏览器 “Firefox”与 Chrome 清单的第 3 版兼容 并发布了路线图，其中定义了要提供给插件的功能和资源。
我们必须记住，宣言的第三版因为中断了许多安全插件和阻止不适当的内容而受到批评，我们甚至已经谈到了 在博客上。
Mozilla 评论说 计划在 Firefox 中实现新清单的几乎所有功能和限制包括声明式内容过滤 API（declarativeNetRequest），但与 Chrome 不同的是，Firefox 不会停止支持 webRequest API 的旧阻塞模式，至少直到新 API 不能完全满足使用 webRequest API 的插件开发者的需求。
这种方法 将确保与 Chrome 插件的兼容性 不破坏与依赖于 webRequest API 的插件的兼容性。
对新清单的主要不满与 webRequest API 向只读模式的转换有关，它允许您连接自己的控制器，这些控制器对网络请求具有完全访问权限并可以动态修改流量。
uBlock Origin 和许多其他插件使用此 API 来阻止不当内容并确保安全。 代替 webRequest API，提出了声明性 NetRequest API，其功能有限，它提供对独立处理阻塞规则的内置过滤引擎的访问，不允许使用自定义过滤算法，并且不允许建立复杂的根据条件重叠的规则。
在火狐浏览器中， 与清单的第三个版本的兼容性 从Chrome 计划于 2021 年底进行测试 新宣言定于 2022 年初发布。
在实施的特点中 从 Firefox 的新宣言中脱颖而出：
- 提供 declarativeNetRequest API，但保留旧的 webRequest API。
- 更改跨域请求的处理：根据新的清单，内容处理脚本将受到与嵌入这些脚本的主页相同的权限限制（例如，如果该页面没有您的访问权限）到位置 API，脚本中的插件也不会获得此访问权限）。 一些与跨域限制相关的更改请求现在可用于在 Firefox 夜间构建中进行测试。
- 后台页面将替换为以后台进程的形式工作的服务工作者。（更改尚未准备好开始测试。）
- 基于 Promise 的 API：Firefox 已经在命名空间 «browser.xml 中支持这种类型的 API。 * »对于清单的第三个版本，它会将其移动到命名空间« chrome。 * »。
- 用于请求权限的新粒度模型：插件将无法一次为所有页面激活，但它只能在活动选项卡的上下文中工作，即用户必须确认插件的工作每个站点。 Mozilla 正在努力加强访问控制，但它旨在让用户能够决定是否允许插件使用不同的选项卡。
- 禁止执行从外部服务器下载的代码（我们说的是插件加载并执行外部代码的情况）。 Firefox 已经使用了外部代码阻止，并且 Mozilla 开发人员已准备好在清单的第三版中添加额外的代码下载跟踪技术。
- 此外，将为内容处理脚本引入单独的内容安全策略 (CSP)，并且将修改现有的 UserScripts 和 contentScripts API 以支持基于工作人员的服务扩展。