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.

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)

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 the manifest.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 the import keyword). 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 import statement and the importScripts() method. Note that import(), 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
  • Update the manifest — The manifest.json must 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
    • Change the manifest version number
    • Update host permissions
      • N/A
    • Update web accessible resources
      • N/A
  • 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
    • Before beginning, read about the differences between background scripts and extension service workers
    • Read Extension service worker basics
    • 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, etc
          • ServiceWorkerRegistration.install
          • chrome.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.active
          • chrome.runtime.onStartup
        • Idle and shutdown
        • Persist data rather than using global variables
        • 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.
    • 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 any StorageArea object is cleared or when the value of a key is changed or set. Note that the each StorageArea instance has its own onChanged event.
        • 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 using sendMessage() (which is available from several extension APIs) aren't intercepted by service worker message handlers. Likewise, messages sent using postMessage() aren't intercepted by extension message handlers. Both types of message handlers—meaning both ServiceWorkerGlobal.message and chrome.runtime.onMessage — are supported in extension service workers. You should prefer extension messaging unless you have a specific reason for using service worker messaging.
    • Update the "background" field in the manifest
    • Move DOM and window calls to an offscreen document
      • N/A
    • Convert localStorage to chrome.storage.local
      • N/A
    • Register listeners synchronously
    • Replace calls to XMLHttpRequest() with global fetch()
      • N/A
    • Persist states
      • N/A
    • Convert timers to alarms
      • N/A
    • Keep the service worker alive (in exceptional cases)
      • N/A
  • Update API calls — Some API calls need to be replaced with more modern equivalents
    • Replace tabs.executeScript() with scripting.executeScript()
      • N/A
    • Replace tabs.insertCSS() and tabs.removeCSS() with scripting.insertCSS() and scripting.removeCSS()
      • N/A
    • Replace Browser Actions and Page Actions with Actions
      • N/A
    • Replace callbacks with promises
    • Replace functions that expect a Manifest V2 background context
      • N/A
    • Replace unsupported APIs
      • N/A
  • 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
      • Update permissions
        • N/A
      • Create declarative net request rules
        • N/A
    • After completing the items above, you may want to review a few common use cases:
      • Block a single URL
        • N/A
      • Redirect-multiple-urls
        • N/A
      • Block cookies
        • N/A
  • 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
    • Remove execution of arbitrary strings
      • N/A
    • Remove remotely hosted code
      • Remove legacy Google Analytics remote code
        • https://developer.chrome.com/docs/extensions/how-to/integrate/google-analytics-4
      • Deal with remote hosted code violations
    • Update content security policy
    • Remove unsupported content security policy values
  • 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
    • Publish a beta testing version
      • N/A: Not going to bother with this, will just test it thoroughly before releasing
    • Gradually roll out your release
      • N/A: This is only available for extensions with more than 10,000 active users.
    • 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.

    • 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.

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:

• Allow right-click context menu to be disabled #16

And tangentially this issue:

• Options page #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:

• Allow right-click context menu to be disabled #16
• Options page #5