Update to Chrome Extension Manifest v3
- https://developer.chrome.com/blog/mv2-transition/
-
Manifest V3 is more secure, performant, and privacy-preserving than its predecessor. It is an evolution of the extension platform that takes into consideration both the changing web landscape and the future of browser extensions.
-
January 17, 2022: New Manifest V2 extensions will no longer be accepted by the Chrome Web Store. Developers may still push updates to existing Manifest V2 extensions, but no new Manifest V2 items may be submitted.
-
January 2023: The Chrome browser will no longer run Manifest V2 extensions. Developers may no longer push updates to existing Manifest V2 extensions.
-
- https://developer.chrome.com/blog/more-mv2-transition/
-
Starting in January in Chrome 112, Chrome may run experiments to turn off support for Manifest V2 extensions in Canary, Dev, and Beta channels.
-
Starting in June in Chrome 115, Chrome may run experiments to turn off support for Manifest V2 extensions in all channels, including stable channel.
-
For developers who still own extensions running Manifest V2, we recommend completing migration to Manifest V3 well ahead of the release of these Chrome versions because those extensions may stop working at any time following the aforementioned dates.
-
- https://developer.chrome.com/docs/extensions/mv3/mv2-sunset/
-
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.
- https://groups.google.com/u/1/a/chromium.org/g/chromium-extensions/c/zQ77HkGmK9E
-
Pausing Manifest V2 phase-out changes
-
we’re postponing any January experiments to turn off Manifest V2 in pre-release channels of Chrome and changes to the featured badge in the Chrome Webstore, and we'll be evaluating all downstream milestones as well. Expect to hear more about the updated phase-out plan and schedule by March of 2023. Our guiding principle will be to give developers sufficient time to update and test their extensions after the launch of these new capabilities before turning off Manifest V2.
-
-
- https://developer.chrome.com/blog/resuming-the-transition-to-mv3
-
Resuming the transition to Manifest V3
-
The phase-out timeline We will begin disabling Manifest V2 extensions in pre-stable versions of Chrome (Dev, Canary, and Beta) as early as June 2024, in Chrome 127 and later. Users impacted by the rollout will see Manifest V2 extensions automatically disabled in their browser and will no longer be able to install Manifest V2 extensions from the Chrome Web Store. Also in June 2024, Manifest V2 extensions will lose their Featured badge in the Chrome Web Store if they currently have one.
- https://chromestatus.com/roadmap
-
Chrome 127 Beta between Jun 12 - Jun 27 Stable Jul 17, 2024
-
- https://chromestatus.com/roadmap
-
- https://blog.chromium.org/2024/05/manifest-v2-phase-out-begins.html
-
Manifest V2 phase-out begins
-
Starting on June 3 on the Chrome Beta, Dev and Canary channels, if users still have Manifest V2 extensions installed, some will start to see a warning banner when visiting their extension management page - chrome://extensions - informing them that some (Manifest V2) extensions they have installed will soon no longer be supported. At the same time, extensions with the Featured badge that are still using Manifest V2 will lose their badge.
-
- https://developer.chrome.com/docs/extensions/develop/migrate/mv2-deprecation-timeline
-
Manifest V2 support timeline Understand when Manifest V2 will stop working for extensions
-
June 3 2024: the Manifest V2 phase-out begins. Starting on June 3 on the Chrome Beta, Dev and Canary channels, if users still have Manifest V2 extensions installed, some will start to see a warning banner when visiting their extension management page - chrome://extensions - informing them that some (Manifest V2) extensions they have installed will soon no longer be supported. At the same time, extensions with the Featured badge that are still using Manifest V2 will lose their badge.
This will be followed gradually in the coming months by the disabling of those extensions. Users will be directed to the Chrome Web Store, where they will be recommended Manifest V3 alternatives for their disabled extension. For a short time after the extensions are disabled, users will still be able to turn their Manifest V2 extensions back on, but over time, this toggle will go away as well.
-
- https://developer.chrome.com/docs/extensions/mv3/known-issues/
- https://developer.chrome.com/docs/extensions/whatsnew/#m104-favicon-api
-
Manifest V3 extensions can now access favicons using a new URL pattern:
chrome-extension://<id>/_favicon/, where is the ID of your extension. This replaces the Manifest V2 platform'schrome://faviconsAPI. See the Favicon API docs for more information.
-
Here is the official migration guide:
- https://developer.chrome.com/docs/extensions/develop/migrate
-
Migrate to Manifest V3
A guide to converting Manifest V2 extensions to Manifest V3 extensions.
Note: Manifest V3 is supported generally in Chrome 88 or later. For extension features added in later Chrome versions, see the API reference documentation for support information. If your extension requires a specific API, you can specify a minimum chrome version in the manifest file.
-
- https://developer.chrome.com/docs/extensions/develop/migrate/checklist
-
Manifest V3 migration checklist
Keep track of your migration progress
-
And this may also be potentially useful:
- https://developer.chrome.com/blog/extension-manifest-converter/
- https://github.com/GoogleChromeLabs/extension-manifest-converter
-
Extension Manifest Converter Extension Manifest Converter is an open source tool that helps convert existing Chrome extensions to Manifest V3.
-
- https://github.com/GoogleChromeLabs/extension-manifest-converter
It seems like Chrome 127 is when MV2 extensions will start getting disabled, and according to the release timeline, that will hit stable release tomorrow (Jul 17 2024):
- https://developer.chrome.com/blog/resuming-the-transition-to-mv3
-
Resuming the transition to Manifest V3
-
The phase-out timeline We will begin disabling Manifest V2 extensions in pre-stable versions of Chrome (Dev, Canary, and Beta) as early as June 2024, in Chrome 127 and later. Users impacted by the rollout will see Manifest V2 extensions automatically disabled in their browser and will no longer be able to install Manifest V2 extensions from the Chrome Web Store. Also in June 2024, Manifest V2 extensions will lose their Featured badge in the Chrome Web Store if they currently have one.
- https://chromestatus.com/roadmap
-
Chrome 127
- Beta between Jun 12 - Jun 27
- Stable tomorrow (Jul 17, 2024)
-
- https://chromestatus.com/roadmap
-
Edit: At 4:11pm on 17/07/2024, it says stable will release in ~8hrs; which would basically be at midnight/the start of 18/07/2024 (AEST)
I tried running the extension-manifest-converter:
- https://github.com/GoogleChromeLabs/extension-manifest-converter
It seems to have merged all of the existing .js files (src/bg/background.js, js/chromeExtensionApiAbstractions.js, js/googleAnalytics.js ) into a single service_worker.js file (and maybe makes some tweaks to that code in doing so). Not sure if this is a requirement, or it's just a limitation of this tool and we can still maintain separate files. Need to look deeper into that:
- https://developer.chrome.com/docs/extensions/develop/migrate/to-service-workers#update-bg-field
-
Replace
"background.scripts"with"background.service_worker"in themanifest.json. Note that the"service_worker"field takes a string, not an array of strings. -
The
"service_worker"field takes a single string. You will only need the"type"field if you use ES modules (using theimportkeyword). Its value will always be"module". For more information, see Extension service worker basics- https://developer.chrome.com/docs/extensions/develop/concepts/service-workers/basics
-
- https://developer.chrome.com/docs/extensions/develop/concepts/service-workers/basics#import-scripts
-
There are two methods of importing scripts into a service worker: the
importstatement and theimportScripts()method. Note thatimport(), often called a dynamic import, is not supported.
-
It also made the following minimal changes to manifest.json (ignoring whitespace changes):
diff --git a/manifest.json b/manifest.json
index 404abe8..a4494be 100644
--- a/manifest.json
+++ b/manifest.json
@@ -1,10 +1,12 @@
{
"name": "New Window With Tabs To Right",
"version": "1.0.1",
- "manifest_version": 2,
+ "manifest_version": 3,
"description": "This extension creates a new window with the tabs to the right of the currently selected tab.",
"homepage_url": "http://devalias.net/dev/chrome-extensions/",
- "content_security_policy": "script-src 'self' https://ssl.google-analytics.com; object-src 'self'",
+ "content_security_policy": {
+ "extension_pages": "script-src 'self' https://ssl.google-analytics.com; object-src 'self'"
+ },
"permissions": [
"tabs",
"contextMenus"
@@ -16,12 +18,8 @@
},
"default_locale": "en",
"background": {
- "scripts": [
- "js/googleAnalytics.js",
- "js/chromeExtensionApiAbstractions.js",
- "src/bg/background.js"
- ],
- "persistent": true
+ "persistent": true,
+ "service_worker": "service_worker.js"
},
"commands": {
"newWindowWithCurrentAndTabsToRight": {
Given the simplicity of this extension, I assume there probably won't be a lot of changes to be made to convert it; and so it's not all that surprising that the changes this conversion tool made were so minimal; but now we really need to go through the migration checklist to figure out more specifically what needs to be done; and if these changes are required/optimal:
- https://developer.chrome.com/docs/extensions/develop/migrate
- https://developer.chrome.com/docs/extensions/develop/migrate/checklist
- [x] Update the manifest — The
manifest.jsonmust be specific to V3. Changes that can be made on their own are described in this section. Manifest changes related to code are described with the code changes they support- [x] Change the manifest version number
- [x] Update host permissions
- N/A
- [x] Update web accessible resources
- N/A
- [x] Migrate to a service worker — A service worker replaces the extension's background or event page to ensure that background code stays off the main thread where it can hurt performance. This change also requires moving DOM, window, and certain extension API calls into offscreen documents
- [x] Before beginning, read about the differences between background scripts and extension service workers
- [x] Read Extension service worker basics
- [x] Read The extension service worker lifecycle
-
Extension service workers respond to both the standard service worker events and to events in extension namespaces. They are presented together because often one type follows another during an extension's use.
- eg.
activate,install,message,messageerror,fetch,notificationclick,notificationclose,push,pushsubscriptionchange, etcServiceWorkerRegistration.installchrome.runtime.onInstalled: fired when the extension (not the service worker) is first installed, when the extension is updated to a new version, and when Chrome is updated to a new version. Use this event to set a state or for one-time initialization, such as a context menu.ServiceWorkerRegistration.activechrome.runtime.onStartup
- Idle and shutdown
- Persist data rather than using global variables
- [x] Choose a minimum Chrome version
- Maybe: Chrome 110: Extension API calls reset the timers. Before this, only running event handlers would keep a service worker alive. Any events that were queued, but for which a handler had not been called would not cause a reset.
- eg.
-
- [x] Read Events in service workers
- Common events
chrome.action: Fired in response to a user interaction with your extension's toolbar icon, whether that action be for a specific page (tab) or for the whole extension.chrome.management: Provides events related to the installation, uninstallation, enabling, and disabling extensions.chrome.notifications: Provides events related to the user's interaction with system notifications generated by the extension.chrome.permissions: Indicates when extension permissions are granted or revoked by the user.chrome.runtime: Provides events related to the extension lifecycle, messages sent from other parts of the extension, and notification of an available extension or Chrome update.chrome.storage.onChanged: Fired whenever anyStorageAreaobject is cleared or when the value of a key is changed or set. Note that the eachStorageAreainstance has its ownonChangedevent.chrome.webNavigation: Provides information about the status of in-flight navigation requests.
- To restrict events to specific use case, or eliminate unnecessary event calls, use APIs that support event filters.
ServiceWorkerGlobal.message: Service worker message passing is available in addition to extension messaging passing, but the two systems are not interoperable. That means that messages sent usingsendMessage()(which is available from several extension APIs) aren't intercepted by service worker message handlers. Likewise, messages sent usingpostMessage()aren't intercepted by extension message handlers. Both types of message handlers—meaning bothServiceWorkerGlobal.messageandchrome.runtime.onMessage— are supported in extension service workers. You should prefer extension messaging unless you have a specific reason for using service worker messaging.
- Common events
- [x] Update the
"background"field in the manifest - [x] Move DOM and
windowcalls to an offscreen document- N/A
- [x] Convert
localStoragetochrome.storage.local- N/A
- [x] Register listeners synchronously
- [x] Replace calls to
XMLHttpRequest()with globalfetch()- N/A
- [x] Persist states
- N/A
- [x] Convert
timerstoalarms- N/A
- [x] Keep the service worker alive (in exceptional cases)
- N/A
- [x] Update API calls — Some API calls need to be replaced with more modern equivalents
- [x] Replace
tabs.executeScript()withscripting.executeScript()- N/A
- [x] Replace
tabs.insertCSS()andtabs.removeCSS()withscripting.insertCSS()andscripting.removeCSS()- N/A
- [x] Replace Browser Actions and Page Actions with Actions
- N/A
- [x] Replace callbacks with promises
- [x] Replace functions that expect a Manifest V2 background context
- N/A
- [x] Replace unsupported APIs
- N/A
- [x] Replace
- [x] Replace blocking web request listeners — Blocking or modifying network requests in Manifest V2 could significantly degrade performance and require excessive access to sensitive user data. The Declarative Net Request API allows extensions to block or modify web content with fewer permissions and without hindering performance
- Instead of programmatically reading network requests and altering them (as you did in Manifest V2), your extension specifies rules that describe actions to perform when a given set of conditions is met
- [x] Update permissions
- N/A
- [x] Create declarative net request rules
- N/A
- [x] Update permissions
- After completing the items above, you may want to review a few common use cases:
- [x] Block a single URL
- N/A
- [x] Redirect-multiple-urls
- N/A
- [x] Block cookies
- N/A
- [x] Block a single URL
- Instead of programmatically reading network requests and altering them (as you did in Manifest V2), your extension specifies rules that describe actions to perform when a given set of conditions is met
- [x] Improve extension security — Manifest V3 improves extension security in several ways. Besides an enhanced content security policy, support is removed for remotely hosted code and execution of arbitrary strings
- [x] Remove execution of arbitrary strings
- N/A
- [x] Remove remotely hosted code
- [x] Remove legacy Google Analytics remote code
- https://developer.chrome.com/docs/extensions/how-to/integrate/google-analytics-4
- Deal with remote hosted code violations
- [x] Remove legacy Google Analytics remote code
- [x] Update content security policy
- [x] Remove unsupported content security policy values
- [x] Remove execution of arbitrary strings
- [ ] Publish your Manifest V3 extension — This section describes how to perform a step-wise roll out to ensure your Manifest V3 extension works as expected by testing it with a limited audience first
- [x] Publish a beta testing version
- N/A: Not going to bother with this, will just test it thoroughly before releasing
- [x] Gradually roll out your release
- N/A: This is only available for extensions with more than 10,000 active users.
- [x] Plan for review times
-
Most extensions are reviewed within three days.
-
If your extension has been pending review for over two weeks, contact developer support to request assistance.
-
- [x] Additional tips
-
To stay on top of user feedback you can add a link to a dedicated support site under the Support tab of your extension listing.
- Manage user feedback
-
Note: You can give users a direct link to the review page of your store item by adding /reviews at the end of your item’s URL:
https://chrome.google.com/webstore/detail/{your-item-id}/reviews - https://developer.chrome.com/docs/webstore/support-users#user-support-tab
-
The Chrome Web Store provides a support hub, where users can leave questions, suggestions, and issues they are facing. To use the support hub, you need to enable it first by going to the Account management page and turning on the Visibility under the Item support section.
-
Note: Currently, this feature does not provide notifications: - You will not be notified when a user posts a new request. - The user will not be notified when you post a response.
-
You can set up a dedicated support site for your users, so that the support link goes there instead of the default forum experience. This site can be anything you like
-
Once you set up the site, go to the Store Listing tab of the developer console and add the link to the Support URL field. Your support link will then take users to your dedicated site.
-
Note: Make sure you turn off the Item support Visibility in the dashboard Account settings to disable the support hub.
-
-
- Manage user feedback
-
- [x] Publish a beta testing version
- [x] Update the manifest — The
Last time I was working on this, I was exploring a way to implement 'options toggles' in the contextMenu, so that, as an example, the user could toggle on/off the 'page' context menu (eg. right-click on page) as per this issue:
- https://github.com/0xdevalias/chrome-NewWindowWithTabsToRight/issues/16
And tangentially this issue:
- https://github.com/0xdevalias/chrome-NewWindowWithTabsToRight/issues/5
Here is the (private) ChatGPT reference that I was exploring that in for context:
- https://chatgpt.com/c/8c6ee698-6b16-4192-acd6-10ceb8d750a9
My notes from then was that "it is seeming like it might be more effort than it's worth, and maybe implementing a proper options page would be a better choice"; though I this was before the ChatGPT o1-preview and o1-mini models were released; so they may be able to come up with a better 'wholistic solution' than I was struggling with with the 4o model on its own.
Here is a new (private) ChatGPT o1-preview reference exploring how to implement this using the same method I was exploring previously:
- https://chatgpt.com/c/66f5127b-a710-8008-954e-4f8448dc1fe2
I'm exploring some ideas for refactoring everything into more modular code files/patterns in this (private) ChatGPT o1-preview conversation:
- https://chatgpt.com/c/66f8e70f-ce4c-8008-92f8-673f9c8c56ae
I'm exploring some ideas for implementing settings / context menu options toggles for changing the default onClick action of the extensions 'action icon' in this (private) ChatGPT o1-preview conversation:
- https://chatgpt.com/c/66f911d6-7e94-8008-88a2-f869748086e2
This relates to the following issues:
- https://github.com/0xdevalias/chrome-NewWindowWithTabsToRight/issues/16
- https://github.com/0xdevalias/chrome-NewWindowWithTabsToRight/issues/5
Since I haven't had a chance to get back to working on this in ages, I just did a quick check that the main functionality in https://github.com/0xdevalias/chrome-NewWindowWithTabsToRight/pull/20 seems to work; and then created a 2.0.0-alpha build of that + submitted it to the Chrome store.
I still intend to get back to finishing that PR 'properly' at some stage and getting it merged/etc; but at the very least, this should unblock the 'removed from the store because no MV3 version' blocker that currently exists from people being able to use the extension.