迁移到 Manifest V3 时的已知问题

本页记录了在过渡到清单 V3 期间解决的平台差距，并解答了有关迁移的常见问题。

弥合了平台差距

添加了以下功能来解决常见的迁移阻碍因素：

  1. 支持 ChromeOS 上的文件处理，以取代 chrome.fileBrowserHandler（Chrome 120）。
  2. 用户脚本支持：允许使用新的 userScripts API (Chrome 120) 注册包含任意代码的内容脚本。
  3. 针对耗时超过 5 分钟的某些操作，添加了额外的强 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 进行多项改进。具体而言：

  • 所有扩展事件和 API 调用都会延长 service worker 的生命周期。
  • 某些选定的使用情形（例如原生消息传递）会使扩展程序服务工作线程保持活动状态的时间超过 5 分钟。

问：是否可以在服务工作器中访问 DOM？
答：我们遵循 Web 平台的做法，不在 Web Worker（包括 Service Worker）中包含 DOM 访问权限。为了支持需要从 Service Worker 进行后台 DOM 访问的使用情形，我们引入了将后台工作委托给提供完整 DOM 访问权限的短期 Offscreen 文档的可能性。

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

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

我们遗漏了什么吗？请告诉我们。