[webextension] Add support for background.scripts and background.page

[kuroppe1819]

↪️ Pull Request

• Open Background scripts for Firefox result in build error when using Manifest V3 #8785

🚨 Test instructions

Add this to your Firefox Add-ons manifest:

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

"background": {
  "page": index.html
}

✔️ PR Todo

• Added/updated unit tests for this change
• Filled out test instructions (In case there aren't any unit tests)
• Included links to related issues/PRs

[101arrowz]

There are now two separate blocks of HMR handling code. This is going to cause issues with HMR: Chrome requires different handling of v2 and v3 to do HMR properly. I'm not sure which version is needed for Firefox's version of Manifest V3. Could you try to investigate?

[101arrowz]

One way to fix the double-handling of hot would be to keep the isMV2 check but copy the background.scripts code into the else block as well. But you'd still need to investigate if this HMR code actually works in Firefox.

[kuroppe1819]

Thanks for review! I have pushed the commit with the fix. 1fbbe8b

I investigated whether HMR works in Firefox and having trouble getting HMR to work in Firefox.

In Manifest V3, the script-src directives may only have 'self', 'none' and 'wasm-unsafe-eval'.

Overwrite at the following value in the dist/manifest.json file after the build, It will work HMR when saving the files specified in the background.scripts.

  "content_security_policy": {
    "extension_pages": "script-src 'self';"
  },

But, occur the following errors when saving the files specified in the content scripts

It's possible that the reason is the stricter CSP constraints in Manifest V3.

In Manifest V3, all CSP sources that refer to external or non-static content are forbidden. The only permitted values are 'none', 'self', and 'wasm-unsafe-eval'. In Manifest V2, a source for a script directive is considered secure if it meets these criteria:
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/content_security_policy

[101arrowz]

That makes sense: Chrome and Firefox both treat MV3 the same with regards to the Content Security Policy. Instead of splitting the HMR logic into two blocks for Chrome and Firefox when isMV2 is false, you'll need to use the Chrome version in both cases, but modify it such that if it's running in Firefox, it also checks for background.scripts.

[kuroppe1819]

📝 Using browser_specific_settings.gecko to switch between Firefox and Chrome. Firefox add-on need an ID in their manifest.json when submitted to AMO.

All Manifest V3 extensions need an add-on ID in their manifest.json when submitted to AMO.
https://extensionworkshop.com/documentation/develop/extensions-and-the-add-on-id/

But, it's not necessary in debugging. I want to know some useful flags.

[sailerinteractive]

I learned that this should be fixed in Parcel >= 2.10.0 However, when im trying to build a Firefox V3 extension with Parcel 2.10.2 im still getting the "Missing property service_worker" error as before with older versions of parcel. Do i somehow need to specify for which browser i would like to bulld in order to activate this fix?

[mischnic]

@sailerinteractive

Do i somehow need to specify for which browser i would like to bulld in order to activate this fix?

No

The current logic says that (among others) these two versions are possible

{
	"background": {
		"service_worker": "xyz"
	}
	...
}

{
	"background": {
		"scripts": ["xyz"]
	}
	...
}

What does your manifest look like?

The corresponding JSON schema sections

parcel/packages/transformers/webextension/src/schema.js

Lines 462 to 478 in c72c336

	background: {
	oneOf: [
	{
	type: 'object',
	properties: {
	service_worker: string,
	type: {
	type: 'string',
	enum: ['classic', 'module'],
	},
	},
	additionalProperties: false,
	required: ['service_worker'],
	},
	mv2Background,
	], // for Firefox
	},

parcel/packages/transformers/webextension/src/schema.js

Lines 79 to 87 in c72c336

	const mv2Background = {
	type: 'object',
	properties: {
	scripts: arrStr,
	page: string,
	persistent: boolean,
	},
	additionalProperties: false,
	};

[sailerinteractive]

Here is a shortened version of the manifest i'm using:

{
    "manifest_version": 3,
    "name": "My Extension",
    "short_name": "MyE",
    "description": "",
    "homepage_url": "https://example.com",
    "version": "10.2",
    "background": {
      "scripts": ["javascript/sw.js"],
      "persistent": false,
      "type": "module"
    },
    "content_scripts": [
    	...
    ],
    "action": {
    	...
    },
    "icons": {
      	...
    },
    "permissions": [
    	...
    ],
    "web_accessible_resources": [ 
    	...
    ],
    "host_permissions": [
    	...
    ]
}

[mischnic]

The schema didn't allow scripts together with type: #9385
You could remove type as a workaround

[sailerinteractive]

Thanks! I can confirm the extension builds when removing the type property. I'm not sure yet what implications that might have when running the extension in Firefox.