Manifest Version 3 background.Service_Worker is currently disabled

[wesley-gaddis]

Is this a feature request or a bug?

feature request ( Error: background.service_worker is currently disabled )

What is the current behavior?

In my extension manifest (v3) file, I have the following defined for my background properties:
"background": { "service_worker": "serviceWorker.js" }

I'm using the --firefox-preview flag/I've also tried this on the nightly build and I get the following error (and the extension isn't loaded)

WebExtError: installTemporaryAddon: Error: Error: Could not install add-on at 'C:\Users\sootieRope\source\repos\tb-extension\TubeBuddy.Web\assets\builds\FireFox_Production_LocalDebug': Error: background.service_worker is currently disabled at RemoteFirefox.installTemporaryAddon (file:///C:/Users/sootieRope/AppData/Roaming/npm/node_modules/web-ext/lib/firefox/remote.js:90:13) at processTicksAndRejections (node:internal/process/task_queues:96:5) at async FirefoxDesktopExtensionRunner.startFirefoxInstance (file:///C:/Users/sootieRope/AppData/Roaming/npm/node_modules/web-ext/lib/extension-runners/firefox-desktop.js:218:27) at async FirefoxDesktopExtensionRunner.run (file:///C:/Users/sootieRope/AppData/Roaming/npm/node_modules/web-ext/lib/extension-runners/firefox-desktop.js:51:5) at async Promise.all (index 0) at async MultiExtensionRunner.run (file:///C:/Users/sootieRope/AppData/Roaming/npm/node_modules/web-ext/lib/extension-runners/index.js:68:5) at async run (file:///C:/Users/sootieRope/AppData/Roaming/npm/node_modules/web-ext/lib/cmd/run.js:178:3) at async Program.execute (file:///C:/Users/sootieRope/AppData/Roaming/npm/node_modules/web-ext/lib/program.js:263:7) at async file:///C:/Users/sootieRope/AppData/Roaming/npm/node_modules/web-ext/bin/web-ext.js:13:1

What is the expected or desired behavior?

serviceworker support, I've tried using the scripts: [] property and it doesn't seem to load either.

Version information (for bug reports)

• Firefox version 108.0a1 (2022-10-19) (64-bit)
• Windows Version 10.0.19044 Build 19044
• Paste the output of these commands:

$ node --version && npm --version && web-ext --version
v16.13.2
8.1.2
7.3.0

[willdurand]

This isn't a bug, Firefox does not support service workers in MV3 yet. Instead, event pages (even-driven background scripts) are recommended, see: https://extensionworkshop.com/documentation/develop/manifest-v3-migration-guide/

[stokito]

I developed an extension for Chrome with the service_worker but FF refuses to even load it. I don't want to use any build tools, this is nonsense.
The FF market share is not that big to play browser wars. You just making life of browser extension devs harder. And most of them are working on their extension in spare time. I don't want to invest my time even into reading of documentation (and you guys definitely also don't want to invest time into writing it). From what I already understand the entire manifest v3 is almost useless and all features might be just added to v2 to make migration more seamless. Now when I searching for some sample I'm confused which version that might be.

As for me the service_worker is a compositely valid usage scenario when I need to preserve a state.
While you didn't managed to negotiate with Chrome team a "single right solution" just enable the feature. Just print a warning.

[0xcaff]

@stokito Before you put firefox on blast, I encourage you to understand why MV3 is not supported by firefox. MV3 is poorly designed, removing features from mv2 like persistent background pages and proxy extensions while providing no alternative. This breaks many useful plugins in the ecosystem and sets the precedent of WebExtension becoming an overfitted API instead of one which is permissive and allows for experimenting with new interaction models.

Some things to read (seems like writing on this topic is sparse):

• https://news.ycombinator.com/item?id=32899846
• https://developer.chrome.com/docs/extensions/migrating/known-issues/

[stokito]

ok, so it's Embrace, extend, and extinguish policy of Google, right?

Anyway, maybe few simple "extend" should be made by FF to just support what we have today in Chrome.
I understand that Google itself gives 99% of profit of Mozilla but still this is a separate product and it should follow own way to avoid attention from anti-trust commision.

Looks like the main goal of Google is to kill extensions i.e. ad blockers to keep mass surveillance and manipulation. But adblockers will anyway found a their way. They can invest their time into learning manifest up to v42.
And people may even just change the browser if extensions won't work.
Thus this just makes no sense and this policy just making life of indie developers harder.

[sarojregmi200]

I 100% agree with what @stokito says, The world of extensions is chaotic. I am stuck trying to figure out simple things and it has been almost more than 2-3 days, all the documentation and stuff are good but still browsers should not do so and establish a common ground. They are as good as the support they provide.

[xerz-one]

A lot of misinformation here. Firefox does, in fact, support Manifest v3: https://www.mozilla.org/firefox/109.0/releasenotes/

The issue right now is that support for background.Service_Worker is disabled. Which is exactly what the error says. This is because implementation is currently ongoing. You can check progress on Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1573659

(disclaimer: I don't work for Mozilla, I just have randomly stumbled upon this issue)

[WaGi-Coding]

The simples way for now (at least for me) is just to use "service_worker": "background_script.js" when i publish to chrome and "scripts": ["background_script.js"] if i publish for Firefox.

Manifest v3 is a really bad thing behind the scenes tho

[sarojregmi200]

Yeah, changing the manifest while publishing the extension is a good solution at least for now.

[stokito]

The FF at least can ignore the incorrect "background": { "service_worker": "serviceWorker.js" } and make a warning instead of the error. Then the same manifest can be used for both browsers.

[WaGi-Coding]

The FF at least can ignore the incorrect "background": { "service_worker": "serviceWorker.js" } and make a warning instead of the error. Then the same manifest can be used for both browsers.

indeed, but which user wants to keep an extension already showing a warning (at least in german even named "Error"("Fehler") instead of warning) when installing it? ^^

[lietu]

use "service_worker": "background_script.js" when i publish to chrome and "scripts": ["background_script.js"] if i publish for Firefox

I can't find any documentation saying scripts is a valid manifest key: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json

Can someone provide a full example of something that actually works?

[manuelarling]

use "service_worker": "background_script.js" when i publish to chrome and "scripts": ["background_script.js"] if i publish for Firefox

I can't find any documentation saying scripts is a valid manifest key: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json

Can someone provide a full example of something that actually works?

You can see it here: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/background

[42Willow]

Related to https://bugzilla.mozilla.org/show_bug.cgi?id=1860304

[divStar]

I suppose I am far better off using manifest v2 for some internal plugin. I've ran into the same issue and I even tried turning extensions.backgroundServiceWorker.enabled to true in v120.0.1 of Firefox (MacOS, Apple Silicon). I hope I'll never have to upgrade the plugin to manifest v3, because it's a hot mess.

Edit: it now seems to allow me to load the plugin with the following manifest:

{
  "manifest_version": 3,
  "name": "plugin",
  "version": "0.0.1",
  "description": "This plugin...",
  "content_scripts": [
    {
      "matches": [
        "https://*/*"
      ],
      "js": [
        "content.js"
      ],
      "css": [
        "content.css"
      ]
    }
  ],
  "action": {
    "default_icon": "assets/images/icon32.png",
    "default_title": "plugin",
    "default_popup": "index.html"
  },
  "background": {
    "service_worker": "background.js"
  },
  "browser_specific_settings": {
    "gecko": {
      "id": "...@...",
      "strict_min_version": "110.0"
    }
  },
  "icons": {
    "16": "assets/images/icon16.png",
    "32": "assets/images/icon32.png",
    "48": "assets/images/icon48.png",
    "128": "assets/images/icon128.png"
  }
}

After changing extensions.backgroundServiceWorker.enabled to true in about:config and restarting Firefox, I was able to get the plugin to load. Since I don't have actual functionality yet, I cannot tell if the service_worker actually works though.

It also shows a proper warning (and not an error message) when a property is unrecognized. However: the **error** about background service-workers being disabled (without any hint, that if one can turn it on for development reasons if need be) is irritating to say the least.

[hugolpz]

You can now use both when coding and testing locally, thank to YujiSoftware:

"background": {
    "service_worker": "background.js",
    "scripts": ["background.js"]
},

EDIT: remove "scripts": ["background.js"] when packaging your webext for Chrome Web store. Thank to wolfmanstout for this hint.

[wolfmanstout]

You can now use both, thank to YujiSoftware:

"background": {
    "service_worker": "background.js",
    "scripts": ["background.js"]
},

One of my extensions got rejected from Chrome Web Store review when I used this approach, and was only accepted after I removed the "scripts" line. This policy doesn't seem to be applied consistently (another extension was permitted), so I might have been able to appeal.

[fregante]

One of my extensions got rejected from Chrome Web Store review when I used this approach

It happened to mine, but I showed them that Chrome does allow that key and they accepted it eventually (I had to submit a new version anyway)

• MV3 version rejected due to background.script npmhub/npmhub#186

The links where:

• https://issues.chromium.org/issues/40257904
• Proposal: declaring background scripts in a neutral way w3c/webextensions#282 (comment)