file:// vs file:/// in content_scripts

RESOLVED WONTFIX
(NeedInfo from)

Status

()

Toolkit
WebExtensions: Untriaged
RESOLVED WONTFIX
2 years ago
a year ago

People

(Reporter: Andy McKay, Unassigned, NeedInfo)

Tracking

({dev-doc-complete})

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

2 years ago
I've found some chrome addons that have:

    "content_scripts":
    [
        {
           ...
            "matches": [ "file://*", "http://*/*", "https://*/*" ],
        }
    ],

We only support file:/// at https://dxr.mozilla.org/mozilla-central/source/toolkit/components/extensions/schemas/manifest.json#248, which means this add-on fails to work.
I don't think we should change this. That pattern technically means a file on any host, with an empty path. Since empty paths are illegal (and we don't support them for any other patterns), and we don't support non-empty hosts in any case, I think the current behavior makes more sense.
Closing this as WONTFIX, since I think this is the desired behavior. We should probably add something to the linter, and at least a mention of it on MDN.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Keywords: dev-doc-needed
Resolution: --- → WONTFIX
Duplicate of this bug: 1278815
I've added this to the list of example invalid match patterns: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Match_patterns#Invalid_match_patterns but please let me now if we need anything else.
Flags: needinfo?(kmaglione+bmo)
Keywords: dev-doc-needed → dev-doc-complete
You need to log in before you can comment on or make changes to this bug.