Manifest V3 support? `scripting.registerContentScripts`

[fregante]

chrome.scripting.registerContentScripts is coming in Manifest V3, but it won't be available on Manifest V2

Bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1054624

Details: https://docs.google.com/document/d/1nRJ6iW-W1MVSpJnQzNrRQFLMsr0RycwsNym06TD5i18/edit

Once the API is finalized I'll have to figure out which way to go:

• continue polyfilling contentScripts.register in Chrome, but with this new API
• polyfill the new chrome API in Firefox and Safari
• deprecate both and just suggest people to use something like:

   if (chrome.scripting?.registerContentScripts) {
   	chrome.scripting.registerContentScripts(details)
   } else if (browser?.contentScripts?.register) {
   	browser. contentScripts.register(details)
   } else {
   	throw new Error('Tough luck')
   }

[fregante]

Firefox seems to have implemented Chrome’s API for the upcoming MV3 support:

https://bugzilla.mozilla.org/show_bug.cgi?id=1736582

This means that:

• MV2 extensions can continue using this polyfill
• MV3 extensions can use chrome.scripting.registerContentScripts
• Extensions that are deployed as both MV2 (Firefox) and MV3 (Chrome), if any, should use:

     if (chrome.scripting?.registerContentScripts) {
       chrome.scripting.registerContentScripts(details)
     } else if (browser?.contentScripts?.register) {
       browser.contentScripts.register(details)
     } else {
       throw new Error('Tough luck')
     }

[fregante]

Findings

Comparing:

• scripting.registerContentScripts
• contentScripts.register

The APIs behave the same

• the scripts have to be registered at every browser start
  • registerContentScripts has an option to persist across sessions
    • it complicates things, but it obviates the following problem
• registration doesn't affect pre-existing tabs (even on browser start 😮)
  • this means every registration should be followed by "inject to existing matching tab"

The APIs behave differently

• scripting.registerContentScripts will stay registered even after the worker unloads
  • due to this difference, contentScripts.register is simply not compatible with event pages or service workers
  • the polyfill doesn't have this limitation, but it might still be buggy: Will inject the scripts multiple times with event pages (persistent: false) #48

On background worker resume

• contentScripts.register: N/A, if it unloads, it loses the registration
• content-scripts-register-polyfill: will register the same script twice, but presumably it won't inject it twice
• scripting.registerContentScripts: will fail unless it's inside onStartup

Resolutions

Chrome

• MV2 persistent: content-scripts-register-polyfill already works
• MV2 non-persistent: content-scripts-register-polyfill must be called from onStartup
• MV3: scripting.registerContentScripts must be called from onStartup

Firefox

• MV2 persistent: contentScripts.register already works
• MV2 non-persistent, when it will be available: same as MV3 Chrome
• MV3 non-persistent, when it will be available: same as MV3 Chrome
• MV3 worker, when it will be available: same as MV3 Chrome

In short:

• prefer scripting.registerContentScripts everywhere
• use onStartup in webext-dynamic-content-scripts

Unresolvable problems

• content-scripts-register-polyfill cannot unregister itself when the background page unloads so: it, together with the original API, should not be used on event pages and workers

[fregante]

Finally: The API is simply not compatible with event pages by design — this is not a polyfill limitation. When the page unloads, the content script is no longer registered.