Mozilla公司 ，尽管 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