Manifest V3 Migration: Solve Chrome Extension Issues & FAQs (Updated 2024)
Migrating to Manifest V3 for Chrome extensions can be tricky. This guide cuts through the confusion, detailing resolved issues, addressing frequently asked questions, and helping you navigate the transition smoothly. We'll focus on providing clear, actionable solutions for developers.
Manifest V3: Addressing the Critical Concerns
Google acknowledges the initial challenges with Manifest V3 and has actively worked to bridge the platform gaps. They've prioritized critical bug fixes based on developer feedback. Before any new deprecation timeline, know that Google wants to ensure a stable transition.
Closed Platform Gaps: What's Been Fixed?
Several key issues have been addressed, making Manifest V3 a more viable option. Check out these improvements:
- ChromeOS File Handling: Use file handling on ChromeOS as a replacement for
chrome.fileBrowserHandlerin Chrome 120. - User Script Support: The new userScripts API (Chrome 120) lets you register content scripts with arbitrary code. This offers flexibility.
- Extended Service Worker Keepalives: Longer operation times are supported for key functions. Chrome 116 added support for
permissions.request(),desktopCapture.chooseDesktopMedia(),identity.launchWebAuthFlow(), andmanagement.uninstall(). Chrome 118 added support forchrome.debugger. - Increased Declarative Net Request (DNR) Rulesets: Chrome 120 increased enabled static rulesets from 10 to 50, and total static rulesets from 50 to 100.
- Expanded Offscreen Document Functionality: The
GEOLOCATIONfeature was added in Chrome 116, increasing functionality of offscreen documents. - Improved
chrome.tabCaptureAPI Support: In Chrome 116,getMediaStreamId()can be called from a service worker, and aMediaStreamcan be obtained from a stream ID in an offscreen document. - Extended Service Worker Lifetimes: Active
WebSocketconnections now extend service worker lifetimes (Chrome 116).
Manifest V3: Common Questions Answered
Let's tackle some of the common concerns developers have about Manifest V3.
Persistent Service Workers: Are They Coming?
No. Google is sticking with the memory-efficient, event-driven model of service workers. This means service workers remain ephemeral in nature. They are making improvements to service workers that include the following:
- Extended Lifetimes: Extension events and API calls now extend service worker lifetimes.
- Specific Use Cases: Select tasks, such as native messaging, will keep service workers alive longer (beyond 5 minutes).
DOM Access in Service Workers: How to Handle It?
Direct DOM access isn't supported in service workers, mirroring the approach of the Web Platform. To work around this, delegate background tasks needing DOM access to short-lived Offscreen documents. They provide full DOM access for these scenarios.
Remote Code in Manifest V3: What's Allowed?
To enhance security, executing arbitrary remotely hosted code is disallowed. However, dynamic code execution isn't entirely restricted. Here are the supported options:
eval()in DevTools extensions- User scripts
- Sandboxed iframes for remotely hosted code
- Remote configuration files, with predetermined execution paths, interpreted at runtime, remain permissible.
Replacing webRequestBlocking: Using declarativeNetRequest
Most request blocking scenarios can be addressed using the declarativeNetRequest API. This API improves performance by avoiding interprocess communication. Complex enterprise or education use cases can still make use of dynamic request blocking.
