1439814 - <all_urls> option not permitted for matching criteria in contentScripts.register()

Status: RESOLVED INVALID

(WebExtensions :: Untriaged, defect)

Description

[alexristich]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.167 Safari/537.36

Steps to reproduce:

In Privacy Badger, we are looking at leveraging the new contentScripts API to allow for conditional injection of content scripts. In implementing this, I used "<all_urls>" as the matching criteria when injecting scripts, as our intention is to load the content scripts on every page except those which are whitelisted.

See here for an example of how we're using the API:
https://github.com/EFForg/privacybadger/pull/1876/files#diff-bc3b0204e92c9ade638a46f86d54e8c8R752


Actual results:

The background page showed the following error:

"Error: Permission denied to register a content script for <all_urls>"  ext-contentScripts.js

The content script subsequently was not injected onto any pages. As such, we switched the matching criteria to "http://*/*", "https://*/*"


Expected results:

The content script should have been injected onto every page except those which were excluded.

Comment 1

[Andrew Swan [:aswan]]

Do you have the <all_urls> permission in manifest.json?  You can't register a content script that is injected into sites that you don't already have host/origin permissions for.

Comment 2

[alexristich]

Hmm, in that case I might need some additional clarification.

Our manifest.json without this API is as follows:
1) We have "http://*/*" and "https:/*/*" listed in the permissions
2) We have our content scripts listed below, each with a "matches" value set to "<all_urls>"

See here: https://github.com/EFForg/privacybadger/pull/1876/files#diff-051a8a7bcae8db1e4cee8eb09b52e619

As part of this change to the contentScripts API, I removed these from manifest.json and put them directly into the contentScripts.register() call: https://github.com/EFForg/privacybadger/pull/1876/files#diff-bc3b0204e92c9ade638a46f86d54e8c8R754

My thinking was that we would be able to port existing values from our manifest.json into a contentScripts.register() call without issue, given the supported syntax is more or less identical. It sounds like this might not be the case, and that to use "<all_urls>" for these registered content scripts, we will need to also modify our permissions in manifest.json to add "<all_urls>". Is this the case? If so, this is likely where I am confused, as this issue doesn't appear in our implementation without this API as described above.

Comment 3

[Andrew Swan [:aswan]]

Your extension has to have host/origin permissions for all the sites you want to register a content script for.  You can do this by declaring the permissions statically in the manifest or by requesting them dynamically at runtime with browser.permissions.request() (I think that in this particular case, declaring them in the manifest is probably most sensible)

You're close with the wildcards but <all_urls> includes a few additional protocols, which is why your call is failing.  Either registering the content script to be injected into "http://*/*" and "https://*/*" or replacing those entries in the manifest permissions property with <all_urls> should fix this.

As for the confusion with the change, I think the issue is that content scripts declared in the manifest don't require a host/origin permission (the browser just includes any domains for which you have registered scripts in the "access your data in the foo domain" install-time notification).  But when you're registering content scripts dynamically, the user needs to know and consent to which domains the extension is getting access, thus the need for an explicit permission.

I hope that makes sense, I'm going to close this bug, if you're still having trouble feel free to re-open it.

Comment 4

[alexristich]

Thanks for clarification, Andrew. That makes sense to me. As you say, I think the confusion comes from the apparent discrepancy that comes with allowing a more broad permission to be specified for content scripts in the manifest than is specified for the extension as a whole. That being said, the reasoning behind not allowing a more broad permission for the dynamically registered content scripts is completely understandable. All that to say I think we're good here :)