-
Notifications
You must be signed in to change notification settings - Fork 10.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[CRX] Migrate Chrome extension to Manifest Version 3 #18681
Conversation
3ed686c
to
86293d4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, with the comments below addressed. I'll have another look at this once that's done before setting the final approval because it's quite a bit of code changes, so I'd like to make sure I haven't missed anything in this round.
I've updated the code + rebased the PR. To more easily tell the real difference, here is the diff: Output of:
|
86293d4
to
0d9d9de
Compare
webRequestBlocking is unavailable in MV3. Non-blocking webRequest can still be used to detect the Referer, but we have to use declarativeNetRequest to change the Referer header as needed.
MV3 does not support chrome_style in options_ui. Remove it and replace it with the minimal amount of styles that still has some spacing around the individual settings for readability.
restoretab.js was added in mozilla#6233 with the purpose of restoring lost tabs when Chrome closes all extension tabs when it reloads the extension. This forced reload can happen when the user toggles the "Allow access to file URLs" option. This logic does not work any more, and since the use of localStorage is a blocker in migrating to MV3, this patch just drops the logic.
In MV3, the background script is a service worker. localStorage is not supported in service workers. Switch to storage.local instead. Data migration is not implemented because it is not needed due to the privacy-friendly design of the telemetry: In practice the data is reset about every 4 weeks, when the major version of Chrome is updated.
- Replace DOM-based pdfHandler.html (background page) with background.js (extension service worker). - Adjust logic of background scripts to account for the fact that the scripts can execute repeatedly during a browser session. Primarily, register relevant extension event handlers at the top level and use in-memory storage.session API to keep track of initialization state. - Extension URL router: replace blocking webRequest with the service worker-specific "fetch" event. - PDF detection: replace blocking webRequest with declarativeNetRequest. This requires Chrome 128+. The next commit will add a fallback for earlier Chrome versions.
The minimum required version is Chrome 103 because wildcard support for web_accessible_resources[].extension_id was introduced in 103, in https://chromium.googlesource.com/chromium/src/+/c9caeb1a080f165f48d2a90559aa35d22965b440 A way to broaden compatibility is to drop that key. By doing so, the minimum required Chrome version is then 96, because of the chrome.storage.session API (and declarativeNetRequestWithHostAccess). Since gulpfile.js already defines "Chrome >= 98" and there is no real point in expanding support to older versions, I'm just setting the minimum version to 103.
0d9d9de
to
4bf7be6
Compare
Addressed #18681 (comment) Output of:
|
Nice work; thank you! |
This PR updates the implementation of the Chrome extension to Manifest Version 3. If you're interested in the individual units of change, review the individual commits and their commit messages.
I manually tested this in Chrome 127, 128 and 130 (and also as old as Chrome 96). Scenarios tested include: http(s) PDFs, link click (verifying that Referer is set), file:-navigations.
Fixes #15161