Proposal: Add excludeTopFrameMatches and excludeTopFrameGlobs.

[polywock]

Many extensions offer, or would like to offer, users the ability to blocklist the extension on certain websites. But currently, the typical method of implementing that is by using a dynamic content script and adding the blocked sites to excludeMatches, but this results in behavior that doesn't align with user expectations.

When a user blocks a site like Reddit, they expect the extension to be completely disabled when they visit Reddit. However, with the current excludeMatches approach: the content script still runs on Reddit if an embedded frame loads content from a different domain. Conversely, if a user visits another website that embeds Reddit content (e.g., a news site displaying a Reddit thread), the extension is blocked from running within that embedded Reddit frame, even if the user did not intend to block it there.

Proposal

scripting.registerContentScripts() should accept excludeTopFrameMatches and excludeTopFrameGlobs. If provided, it will exclude based on the top frame's URL.

This allows extensions to, more easily, implement a blocklist system that's user intuitive.

First proposed by @kzar : https://issues.chromium.org/issues/40202338
Thanks @ghostwords for pointing it out.

Current workarounds

Let the content script load and then check the top frame URL (e.g. Location.ancestorOrigins) to decide whether it should run. However, this is inefficient since the script still loads, using memory and resources even when it doesn’t execute.

[gorhill]

Related issue: #668

[ghostwords]

Chromium bug: https://issues.chromium.org/issues/40202338

[polywock]

Another related issue #117.

[polywock]

@Rob--W My concerns with the location.ancestorOrigins approach...

1. The content script still must load and that might have memory or other performance implications. Particularly for power users with large amount of tabs.
2. If the user adds a sensitive website (bank, etc) to the blocklist, it would be ideal if the content script never loads in the first place. A lower footprint is always better. Even if the extension is not intentionally being nefarious, bad code can always enter the system (e.g. an NPM package being hacked, etc).
3. In certain cases just loading a content script, even if exiting early, could result in conflicts or issues with a website. I've had that problem a few times with polyfills.

[ghostwords]

Furthermore, as @gorhill already pointed out in #668 (comment), how would static document_start main world scripts know what to compare location.ancestorOrigins to? We don't have dom.execute() yet, and the suggested hacks are not reasonable (too complex, almost certainly come with pitfalls/downsides/caveats).

We're asking for a simple API that does what we want, without requiring each and every developer to implement hacks or unnecessary/bug prone custom matching logic.

[polywock]

@ghostwords Not sure about that context, but In my use case, it can be used to disable the extension based on the top frame's origin. E.g. the user adds reddit.com to a list of websites they want disabled, the extension checks location.ancestorOrigin on every subframe to confirm the top frame's origin isn't reddit.com. Although, I do think that it would be much safer, performative and bug free as a declarative API.

[oliverdunk]

To reiterate what I said in the last public meeting, I'm personally (not speaking on behalf of Chrome) supportive of this request. We would want to restrict matching to be based on the origin (or we could use a match pattern with a forced-wildcard path). Matching based on an actual path is much harder from a technical perspective.

There is already a lot of precedence for a "disable this site" option in the extension ecosystem, so I don't feel as strongly that we need to prove the demand for this.

In parallel, I do also like @Rob--W's suggestion in #668 to solve this with content script params. It wouldn't avoid injecting a content script entirely, so there is still value in this request, but it definitely seems like it would be an improvement and would be worth pursuing in parallel. I know that proposal hasn't moved anywhere in a long time, but chatting with Rob recently I think we are both keen to see if we can get it some momentum again.