web_accessible_resources[].matches should only contain /* as path.

MDN currently documents matches at web_accessible_resources as:

A list of URL match patterns specifying the pages that can access the resources. Only the origin is used to match URLs. Origins include subdomain matching. Paths are ignored.

This documentation does not match the actual behavior: the implementation does not set options.ignorePath = true; at https://searchfox.org/mozilla-central/rev/f60cf6bfa8bd096efd9bb3a445364f5a0f32897a/toolkit/components/extensions/WebExtensionPolicy.cpp#151-155

Chrome's behavior is quite strict, it refuses to load the manifest when the path is anything other than /*: https://source.chromium.org/chromium/chromium/src/+/refs/heads/main:extensions/common/manifest_handlers/web_accessible_resources_info.cc;l=120-122;drc=b646f894a92491033bde5d1e75aba6f44c524f0e

Chrome's documentation states the following (note: the * is missing, / should be /*):

Google Chrome emits an "Invalid match pattern" error if the pattern has a path other than '/'.

I fixed up the documentation in https://github.com/mdn/content/pull/26801, covered by point:

The docs states "Paths are ignored.", but that is not the case in any browser, see https://bugzilla.mozilla.org/show_bug.cgi?id=1833415

I audited all public extensions on AMO, and there are only two extensions whose matches list does not meet the requirements (i.e. having a match pattern whose path is not /*; these extensions would fail to load in Chrome).

I audited using the following commands along from https://github.com/Rob--W/webextanal . After getting all MV3 manifests, I manually checked the few extensions that have more than one entry in web_accessible_resources, and after that I manually filtered to find all extensions that have a match pattern that does not end with /* (note: <all_urls> is also valid).

$ cat initialinput | filter-manifest manifest_version 3 | sed 's@$@/manifest.json@' > mv3.txt
$ cat mv3.txt | filter-manifest web_accessible_resources.1 . > list-of-files-to-inspect-manually.txt
$ cat mv3.txt | filter-manifest web_accessible_resources.0.matches '://[^/]+/($|,|[^*]|\*[^,])'
/path/to/extracted/2795587/214f61000a8254f9393c8fea2bc1f906b2bba5b6094aea7b7f76059a825dbbeb/manifest.json
/path/to/extracted/2793985/507d5ca916c1f90cee20f55b1df03a219fdfdd3dcb0efa8cb2bd35d7da037f50/manifest.json

First example: https://addons.mozilla.org/en-US/firefox/addon/freeservers/ (version 0.13)

            "matches": [
                "https://*.roblox.com/games/*",
                "https://*.roblox.com/",
                "https://roblox.com/"
            ]

Second example: https://addons.mozilla.org/en-US/firefox/addon/slides-animator/ (version 0.6.1)

            "matches": [
                "https://docs.google.com/presentation/d/*"
            ]

Safari's behavior is identical to Firefox's behavior, i.e. the path can be anything, including anything other than /*.

Chrome's web_accessible_resources[].matches implementation is in https://bugs.chromium.org/p/chromium/issues/detail?id=1133624, and a public version of the design doc is available at https://docs.google.com/document/d/1_rHLFKfspPwMi6_CmOvUTmymobMYvQKhXkmN9UyP6ZE . This doc's motivation for the format of matches is inspired by externally_connectable.matches, but even in that implementation matches does not have restrictions on the path: https://source.chromium.org/chromium/chromium/src/+/refs/heads/main:extensions/common/manifest_handlers/externally_connectable.cc;l=98-112;drc=9c68f2c46912577bf73bcf032c0f8c00379a0bca

(assigning because I'm sorting out the desired behavior in conversations with Apple and Google).

Result of conversations with Google and Apple:

• Chrome intentionally allows "/*" only because they believe that there is no (security) benefit from supporting paths.
• Chrome will fix their documentation.
• Firefox and Safari support any path, not just /*.

The documentation that I authored (comment 1) states Only the origin is used to match URLs. Origins include subdomain matching. Paths must be set to <code>/*</code>. This doesn't mention Firefox and Safari's support for non-wildcard paths, so we should add that to the BCD and/or MDN.