Web Extension Transformer: a broken web_accessible_resources field is added

[fregante]

• Follows Add support for Web Extension manifest V3 #7050

🐛 bug report

When building a web extension, it seems that the hosts specified in the content scripts are copied to the web_accessible_resources field, even if unnecessary, breaking the manifest altogether in some cases.

🎛 Configuration (.babelrc, package.json, cli command)

No custom configuration. It happens on both build and watch.

🤔 Expected Behavior

No web_accessible_resources unless required:

{
	"name": "Awesome Extension",
	"version": "0.0.0",
	"manifest_version": 3,
	"content_scripts": [
		{
			"matches": ["https://github.com/fregante/browser-extension-template/*"],
			"css": ["manifest.b7514168.css"]
		}
	]
}

or at least use a supported origin glob:

{
	"name": "Awesome Extension",
	"version": "0.0.0",
	"manifest_version": 3,
	"content_scripts": [
		{
			"matches": ["https://github.com/fregante/browser-extension-template/*"],
			"css": ["manifest.b7514168.css"]
		}
	],
	"web_accessible_resources": [
		{
			"matches": ["https://github.com/*"],
			"extension_ids": [],
			"resources": []
		}
	]
}

😯 Current Behavior

{
	"name": "Awesome Extension",
	"version": "0.0.0",
	"manifest_version": 3,
	"content_scripts": [
		{
			"matches": ["https://github.com/fregante/browser-extension-template/*"],
			"css": ["manifest.b7514168.css"]
		}
	],
	"web_accessible_resources": [
		{
			"matches": ["https://github.com/fregante/browser-extension-template/*"],
			"extension_ids": [],
			"resources": []
		}
	]
}

💻 Code Sample

Input manifest:

{
	"name": "Awesome Extension",
	"version": "0.0.0",
	"manifest_version": 3,
	"content_scripts": [
		{
			"matches": [ "https://github.com/fregante/browser-extension-template/*" ],
			"css": [ "content.css" ]
		}
	]
}

🌍 Your Environment

Software	Version(s)
Parcel	2.0.0-nightly.1049
parcel/config-webextension	2.4.2-nightly.2674
Node	v16.4.2
npm/Yarn	7.18.1
Operating System	macOS 11

[101arrowz]

We'd have to parse out the matches key for content scripts to make this work properly. It's probably better just to not use the matches field at all (though marginally less secure). We could also have the packager skip injecting a file into web_accessible_resources if it's already there.

[fregante]

parse out

I think the main issue is that the content scripts allow pathnames other than /* while the other key doesn't. You can probably pass the glob to a regular URL constructor and replace the pathname. That might be a quick fix, as well as avoiding adding web accessible resources when the list of resources is empty.

[101arrowz]

content scripts allow pathnames other than /*

They also allow raw protocols, <all_urls>, and potentially a bunch of other stuff that it's really not worth the effort to handle. The main reason matches exists is to try to combat fingerprinting AFAIK, you can check for the presence of popular extensions for very accurate browser fingerprinting. But I'd think the injected sites are the ones most likely to want to detect the extension's presence in the first place, so I'm not sure if there's really a good way to avoid this anyway.

For now I'm going to submit a PR that just removes the matches field, maybe it can be worked on more later.