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.
- Before announcing a new timeline for deprecation, we finished addressing the prioritized platform gaps and closed the critical bugs that were documented on this page.
- We gave developers time to build, by guaranteeing at least six months between a timeline announcement and the pending experiments for removing support for Manifest V2.
Closing the platform gap
We are committed to closing the following gaps before announcing a new Manifest V2 deprecation timeline:
Issues were collected based on feedback from partners, bug reports, and developers. We will continue our ongoing work to improve stability and overall performance of the extension platform.
There are currently no open issues considered a critical platform gap.
The following issues have recently been addressed:
- Support for File handling on ChromeOS as a replacement for
chrome.fileBrowserHandler[Chrome 120]. - User Script support: Allow registering content scripts with arbitrary code with the new userScripts API [Chrome 120].
- Additional strong service worker keepalives for certain operations taking longer than five minutes.
- Added in Chrome 116 for
permissions.request(),desktopCapture.chooseDesktopMedia(),identity.launchWebAuthFlow()andmanagement.uninstall(). - Added in Chrome 118 for
chrome.debugger
- Added in Chrome 116 for
- 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].
- Extend Offscreen document functionality to support more reasons for using an offscreen document. Added
GEOLOCATIONin Chrome 116. - Improving support for the
chrome.tabCaptureAPI [Chrome 116]:- Support calling
getMediaStreamId()from a service worker. - Support obtaining a
MediaStreamfrom a stream ID in an offscreen document.
- Support calling
- Extending service worker lifetimes while there are active
WebSocketconnections [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.
- 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 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 - Support for user scripts.
- Executing remotely hosted code in sandboxed iframes
- 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, 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.
Did we miss something? Please let us know.