> [!NOTE]
> **Note:** The Manifest V2 phase-out is complete. See our [May 2024 blog post](https://blog.chromium.org/2024/05/manifest-v2-phase-out-begins.html) and the [Manifest V2 support timeline page](https://developer.chrome.com/docs/extensions/develop/migrate/mv2-deprecation-timeline.md.txt) for details.

This page documents the platform gaps resolved during the transition to Manifest V3 and answers frequently asked migration questions.

## Resolved platform gaps

The following capabilities were added to address common migration blockers:

1. **Support for [File handling on ChromeOS](https://developer.chrome.com/docs/extensions/how-to/web-platform/file-handling-chromeos.md.txt)** as a replacement for [`chrome.fileBrowserHandler`](https://developer.chrome.com/docs/extensions/reference/api/fileBrowserHandler.md.txt) (Chrome 120).
2. **User Script support:** Allow registering content scripts with arbitrary code with the new [userScripts API](https://developer.chrome.com/docs/extensions/reference/api/userScripts.md.txt) (Chrome 120).
3. Additional **strong service worker keepalives** for certain operations taking longer than five minutes.
   - Added in Chrome 116 for `permissions.request()`, `desktopCapture.chooseDesktopMedia()`, `identity.launchWebAuthFlow()` and `management.uninstall()`.
   - Added in Chrome 118 for `chrome.debugger`.
4. **Increase the number of static and enabled rulesets** for Declarative Net Request (DNR). Enabled static rulesets increased from 10 to 50 and total static rulesets from 50 to 100 (Chrome 120).
5. Extend **[Offscreen document](https://developer.chrome.com/docs/extensions/reference/api/offscreen.md.txt) functionality** to support more reasons for using an offscreen document. Added [`GEOLOCATION`](https://developer.chrome.com/docs/extensions/how-to/web-platform/geolocation.md.txt) in Chrome 116.
6. Improving **support for the [`chrome.tabCapture`](https://developer.chrome.com/docs/extensions/reference/api/tabCapture.md.txt) API** (Chrome 116):
   - Support calling `getMediaStreamId()` from a service worker.
   - Support obtaining a `MediaStream` from a stream ID in an offscreen document.
7. **Extending service worker lifetimes** while there are active [`WebSocket` connections](https://developer.chrome.com/docs/extensions/how-to/web-platform/websockets.md.txt) (Chrome 116).

## Manifest V3 frequently asked questions

**Q: Do we plan to support persistent 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](https://developer.chrome.com/docs/extensions/develop/concepts/service-workers/lifecycle.md.txt).
- Selected use cases such as native messaging will keep extensions service workers alive for longer than 5 min.

**Q: Is there a way to access the DOM in service workers?**   

**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](https://developer.chrome.com/docs/extensions/reference/api/offscreen.md.txt) which provide full DOM access.

**Q: Will there be a way to support remote code in 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:

- [Support for `eval()` in DevTools extensions](https://developer.chrome.com/docs/extensions/reference/api/devtools/inspectedWindow.md.txt#method-eval)
- Support for [user scripts](https://developer.chrome.com/docs/extensions/reference/api/userScripts.md.txt).
- [Executing remotely hosted code in sandboxed iframes](https://developer.chrome.com/docs/extensions/how-to/security/sandboxing-eval.md.txt)
- 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?**   

**A:** We are confident that most request blocking use cases can be solved with the new [`declarativeNetRequest` API](https://developer.chrome.com/docs/extensions/reference/api/declarativeNetRequest.md.txt), 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](https://support.google.com/chrome/a/answer/9296680), dynamic request blocking is still supported.

**Did we miss something?** [Please let us know](https://groups.google.com/a/chromium.org/g/chromium-extensions).