迁移到 Manifest V3 时的已知问题

最近，我们宣布了对 Manifest V2 弃用时间表的变更。虽然我们仍会坚定地努力推出 Manifest V3，但也深知我们这方面还有很多工作要做。

  • 在宣布新的弃用时间表之前，我们已完成优先处理的平台问题，并修复了本页中记录的关键 bug。
  • 我们为开发者留出了充足的时间进行构建，并保证从时间表公告发布到待完成的实验（即将取消对 Manifest V2 的支持）之间至少有 6 个月的时间。

缩小平台差距

我们致力于在宣布新的 Manifest V2 弃用时间表之前弥补以下缺口：

问题是根据合作伙伴、bug 报告和开发者的反馈收集的。我们将继续不断努力，以提高扩展程序平台的稳定性和整体性能。

目前没有可视为严重平台差距的待解决问题。

以下问题最近已解决：

  1. 支持 ChromeOS 上的文件处理功能，以替代 chrome.fileBrowserHandler [Chrome 120]。
  2. 用户脚本支持：允许使用新的 userScripts API [Chrome 120] 注册使用任意代码的内容脚本。
  3. 对于耗时超过五分钟的某些操作，提供额外的强 Service Worker keepalive。
    • 在 Chrome 116 中为 permissions.request()、desktopCapture.chooseDesktopMedia()、identity.launchWebAuthFlow() 和 management.uninstall() 添加。
    • 在 Chrome 118 中为 chrome.debugger 添加
  4. 为声明性网络请求 (DNR) 增加静态和已启用规则集的数量。启用的静态规则集从 10 个增至 50 个，静态规则集总数从 50 个增至 100 个 [Chrome 120]。
  5. 扩展屏幕外文档功能，以支持使用屏幕外文档的更多原因。在 Chrome 116 中添加了 GEOLOCATION。
  6. 改进对 chrome.tabCapture API 的支持 [Chrome 116]：
    • 支持从 Service Worker 调用 getMediaStreamId()。
    • 支持从屏幕外文档中的数据流 ID 获取 MediaStream。
  7. 在 WebSocket 连接处于活跃状态时延长 Service Worker 的生命周期 [Chrome 116]。

Manifest V3 常见问题解答

问：我们计划支持持久性 Service Worker 吗？
答：从后台脚本迁移到 Service Worker 的一个主要原因是，事件驱动型编程模型的内存效率更高，因为 Service Worker 具有短暂性。因此，我们不打算支持持久性 Service Worker。不过，为了满足扩展程序开发者的具体需求，我们将继续对 Service Worker 进行许多改进。具体而言：

  • 所有扩展程序事件和 API 调用都会延长 Service Worker 生命周期。
  • 原生消息传递等选定用例会使扩展程序 Service Worker 保持活跃状态超过 5 分钟。

问：有没有办法访问 Service Worker 中的 DOM？
答：我们遵循 Web 平台的做法，即不在 Web 工作器（包括 Service Worker）中包含 DOM 访问权限。为了支持需要从 Service Worker 进行后台 DOM 访问的用例，我们引入了将后台工作委托给提供完整 DOM 访问权限的短期屏幕外文档的可能性。

问：Manifest V3 是否可以支持远程代码？
答：为了提高 Chrome 扩展程序的安全性，我们将继续禁止在 Chrome 扩展程序中执行任意远程托管代码。不过，这并不意味着我们会禁止执行各种类型的动态代码。我们仍然支持在 Chrome 扩展程序中动态执行代码的不同选项：

问：我的 Manifest V2 扩展程序依赖于 webRequestBlocking，而 Manifest V3 不支持该技术。我如何继续在 Manifest V3 中提供相同的功能？
答：我们相信，大多数请求阻塞用例都可以通过新的 declarativeNetRequest API 解决。它还能带来以下好处：避免进程间通信的性能开销、对每个请求执行代码，或者在发送请求时需要活跃的扩展进程。不过，对于复杂的企业（或教育）用例，系统仍然支持动态请求屏蔽。

还有其他问题吗？请告诉我们。