Add proposal for topFrameMatches and excludeTopFrameMatches
#802
Conversation
API proposal to allow content script registration (both static and dynamic) to be restricted based on the origin of the top-level frame.
|
If linking my GitHub to the W3 account is enough, the ipr issue should be resolved. |
| * And if `topFrameMatches` was specified, the origin of the top-level frame's URL matches at least one pattern in `topFrameMatches`. | ||
| * And if `excludeTopFrameMatches` was specified, the origin of the top-level frame's URL does *not* match any validated pattern in `excludeTopFrameMatches`. | ||
|
|
||
| **Origin Definition:** The origin consists of the scheme, host, and port (e.g., `https://www.example.com:443`). Match patterns are compared against this origin. The path component of the top-level URL is ignored during matching, as enforced by the validation rule disallowing specific paths in the patterns. |
There was a problem hiding this comment.
Although this seems precise, it is leaving room for interpretation. I think that it would make most sense to use the origin following the interpretation of match_origin_as_fallback: true as specified at https://w3c.github.io/webextensions/specification/index.html#determine-the-url-for-matching-a-document . That part of the spec draft was added in #542
My motivation for this interpretation is to make sure that about:blank, blob: etc can be matched (which would naturally happen if you look at the document's origin) AND also that http(s) documents would be matched even if Content-Security-Policy: sandbox were to be used, which would give it an opaque origin.
And also to specify what should happen if an origin cannot be determined, so that we don't have issues like https://bugzilla.mozilla.org/show_bug.cgi?id=1798225 ([DNR] Matching of missing initiators and/or with an opaque origin)
There was a problem hiding this comment.
Considering potential support for <extension_urls>, we should specify how browsers should handle match patterns they do not understand. Whether or not excludeTopFrameMatches should become a no-op or simply prevent the content script from running.
There was a problem hiding this comment.
@Rob--W Updated the proposal to use the W3C spec for origin matching and to clarify behavior for unknown origin. Let me know if it didn't hit the mark.
@carlosjeurissen It's a cop out, but I've added -> "The browser must validate all patterns provided in topFrameMatches and excludeTopFrameMatches as it would validate patterns provided by matches and excludeMatches" as a base validation step for now.
Co-authored-by: carlosjeurissen <[email protected]>
Related issue: #763