chrome扩展开发手册·迁移到Manifest V3时的已知问题

• 译自: chrome扩展开发手册·迁移到Manifest V3时的已知问题

> Known issues when migrating to Manifest V3

迁移到Manifest V3时的已知问题

Published on Friday, September 23, 2022 • Updated on Wednesday, May 10, 2023
发布于2022年9月23日星期五·更新于2023年5月10日星期三

Extensions News 扩展新闻

Table of contents 目录

• Closing the platform gap
• Manifest V3 frequently asked questions

December 9, 2022: The Manifest V2 deprecation timelines are under review and the experiments scheduled for early 2023 are being postponed. For more information, read the update in the chromium-extensions Google Group.
2022年12月9日：Manifest V2弃用时间表正在审查中，计划于2023年初进行的实验正在推迟。有关详细信息，请阅读Chrome扩展Google Group中的更新。

Recently, we announced changes to the Manifest V2 deprecation timeline, and while we remain firmly committed to Manifest V3 we acknowledge there is more work to do on our part.
最近，我们宣布了对Manifest V2弃用时间轴的更改，虽然我们仍然坚定地致力于Manifest V3，但我们承认我们还有更多的工作要做。

• Before announcing a new timeline for deprecation, we will finish addressing prioritized platform gaps and close the critical bugs that are documented on this page.
  在宣布新的弃用时间轴之前，我们将完成解决优先级的平台差距，并关闭此页面上记录的关键错误。
• We will give developers time to build, guaranteeing at least 6 months between a timeline announcement and any experiments removing support for Manifest V2.
  我们将给予开发人员时间来构建，保证在时间轴公告和任何移除对Manifest V2支持的实验之间至少有6个月的时间。

# Closing the platform gap

缩小平台差距

We are committed to closing the following gaps before announcing a new Manifest V2 deprecation timeline:
在宣布新的Manifest V2弃用时间轴之前，我们致力于缩小以下差距：

1. User Script support: Allow registering content scripts with arbitrary code by adding new functionality to the scripting API. (See our proposal for details.)
   用户脚本支持：通过向脚本API添加新功能，允许使用任意代码注册内容脚本。(See我们的建议详情）。

2. Additional strong service worker keepalives for certain operations taking longer than five minutes.
   额外的强服务工作进程keepalive用于某些操作，所需时间超过五分钟。

   Work in progress: Added in Chrome 116 for

   permissions.request()
   

   ,

   desktopCapture.chooseDesktopMedia()
   

   ,

   identity.launchWebAuthFlow()
   

   and

   management.uninstall()
   

   .
   正在进行的工作：在Chrome 116中为

   permissions.request()
   

   desktopCapture.chooseDesktopMedia()
   

   、

   identity.launchWebAuthFlow()
   

   和

   management.uninstall()
   

   添加。

3. Increase the number of static and enabled rulesets for Declarative Net Request (DNR).
   增加声明性网络请求（DNR）的静态和启用的规则集的数量。

4. Extend Offscreen document functionality to support more reasons for using an offscreen document.
   扩展离屏文档功能，以支持使用离屏文档的更多原因。

   Work in progress: GEOLOCATION added in Chrome 116
   正在进行的工作：在 GEOLOCATION Chrome 116中添加

5. Support File Handling API on ChromeOS as a replacement for ```
   chrome.fileBrowserHandler

   支持ChromeOS上的文件处理API作为替代。
   
   

These issues have been collected based on feedback from partners, bug reports, and developers. In addition to these, we will continue our ongoing work to address stability issues and improve overall performance.
这些问题是根据合作伙伴、bug报告和开发人员的反馈收集的。除此之外，我们将继续我们正在进行的工作，以解决稳定性问题和提高整体性能。

The following issues have recently been addressed:
最近处理了以下问题：

1. Improving support for the chrome.tabCapture API [Chrome 116]:
   改进对API的支持[Chrome 116]：
   • Support calling getMediaStreamId() from a service worker.
     支持从服务工作者呼叫。
   • Support obtaining a MediaStream from a stream ID in an offscreen document.
     支持从屏幕外文档的流ID中获取。
2. Extending service worker lifetimes while there are active WebSocket connections [Chrome 116].
   在存在活动连接时延长service worker的生命周期[Chrome 116]。

# Manifest V3 frequently asked questions

Manifest V3常见问题

Q: Do we plan to support persistent Service Workers? 问：我们是否计划支持持久的Service Workers？
A: One of the key reasons for migrating from background scripts to service workers is the more memory efficient event-driven programming model which comes from the ephemeral nature of service workers. Consequently, we are not planning to support persistent service workers. However, to address the specific needs of extension developers, we are continuing to make many improvements to service workers. In particular:
答：从后台脚本迁移到服务工作者的一个关键原因是更有效的内存事件驱动编程模型，它来自服务工作者的短暂性。因此，我们不打算支持持久的服务工作者。但是，为了满足扩展开发人员的特定需求，我们将继续对服务工作者进行许多改进。特别是：

• All extension events and API calls will extend the service worker lifetime.
  所有扩展事件和API调用都将延长服务工作者的生存期。
• Selected use cases such as native messaging will keep extensions service workers alive for longer than 5 min.
  选定的用例（如本机消息传递）将使扩展服务工作者的活动时间超过5分钟。

Q: Is there a way to access the DOM in service workers? 问：有没有办法在service worker中访问DOM？
A: We follow the approach taken by the Web Platform of not including DOM access in web workers (which includes service workers). To support use cases requiring background DOM access from service workers we’ve introduced the possibility to delegate background work to short-lived Offscreen documents which provide full DOM access.
答：我们遵循Web平台所采用的方法，即不将DOM访问包括在Web工作者（包括服务工作者）中。为了支持需要从服务工作者进行后台DOM访问的用例，我们引入了将后台工作委托给短期Offscreen文档的可能性，这些文档提供完整的DOM访问。

Q: Will there be a way to support remote code in Manifest V3? 问：在Manifest V3中会有支持远程代码的方法吗？
A: To make Chrome Extensions more secure, we will continue to disallow executing arbitrary remotely hosted code in Chrome extensions. However, this does not mean we disallow all kinds of dynamic code execution. We still support different options of dynamically executing code in Chrome extensions:
答：为了使Chrome扩展程序更加安全，我们将继续禁止在Chrome扩展程序中执行任意远程托管代码。然而，这并不意味着我们不允许所有类型的动态代码执行。我们仍然支持在Chrome扩展中动态执行代码的不同选项：

• Support for eval() in DevTools extensions
  支持DevTools扩展
• Support for user scripts.
  支持用户脚本。
• Executing remotely hosted code in sandboxed iframes
  在沙箱iframe中执行远程托管代码
• Remote hosted configuration files which can be interpreted at runtime in the extension package. However, possible execution paths need to be predetermined.
  可以在运行时在扩展包中解释的远程托管配置文件。然而，可能的执行路径需要预先确定。

Q: My Manifest V2 extension relies on webRequestBlocking which is not supported in Manifest V3. How can I continue to provide the same functionality in Manifest V3? 问：我的Manifest V2扩展依赖于Manifest V3不支持的webRequestBlocking。如何在Manifest V3中继续提供相同的功能？
A: We are confident that most request blocking use cases can be solved with the new ```
declarativeNetRequest

 API , which has the added benefit of avoiding the performance overhead of interprocess communication, executing code on every request, or requiring an active extension process at the time of the request. However, for complex enterprise (or education) use cases, dynamic request blocking is still supported.  
答：我们相信，大多数请求阻塞用例都可以通过新的API解决，它具有避免进程间通信的性能开销、在每个请求上执行代码或在请求时需要活动扩展进程的额外好处。但是，对于复杂的企业（或教育）用例，仍然支持动态请求阻塞。

> `Did we miss something?` Please let us know.  
我们错过什么了吗请告诉我们。

> Updated on Wednesday, May 10, 2023 • Improve article