Proposal: about: matching

[erosman]

Proposal: about: matching

Background

Match patterns does not match about: URLs.
While some APIs such as Content scripts or scripting support about: matching via additional options (match_about_blank, match_origin_as_fallback), there are others that don't have such options.

menus/contextMenus is a commonly used example where documentUrlPatterns is insufficient for this purpose.

I recently needed to limit the context-menu to ['http://*/*', 'https://*/*','about:newtab', 'about:blank']. The only option is to omit documentUrlPatterns which results in the contextMenu appearing in many unwanted pages such as file://, toolbar popups, and extension pages.

Proposal

Provide a method to match about:newtab, about:blank, etc

Suggestions

A few possibilities:

1. Include the ability to match about:newtab, about:blank and in Match patterns (preferable)
2. Add additional matching options (e.g. similar to scripting) to APIs that don't have it

[xeenon]

menus/contextMenus is a commonly used example where documentUrlPatterns is insufficient for this purpose

It's not just insufficient, it's completely unsupported outside Firefox. There are at least 3 tickets like https://issues.chromium.org/issues/41305289 documenting this but they're all expired/closed.

Safari supports documentUrlPatterns.

[fregante]

Safari supports documentUrlPatterns.

Indeed it appears to have been resolved since I first noticed this in 2021 (Safari 14.0.1) fregante/webext-permission-toggle#14

So it's just a Chrome issue

[fregante]

I recently needed to limit the context-menu to ['http://*/*', 'https://*/*','about:newtab', 'about:blank'].

I think that allowing explicit 'about:blank' strings would be safer than a blanket about:* pattern:

• no extension should probably have access to about:debugging or about:flags
• it's easier to statically detect what an extension intends to alter/access

So the array of strings as you wrote it sounds good to me. Dropping match_about_blank would also be a good followup for MV4

[erosman]

I think that allowing explicit 'about:blank' strings would be safer than a blanket about:* pattern:

That is also what I meant (as per Proposal). I will update the topic to make it clearer.

[dotproto]

It would be helpful to get some more concrete use cases where matching about: pages would be helpful or necessary.

Between the original issue description, #756, and fregante/webext-permission-toggle#14 I gather that one of the problems that you're looking to solve is that you don't want to show context menus on pages in situations where the extension cannot provide its features.

@erosman, can you provide more context on the scenario you described where you wanted to provide a context menu on 'about:newtab' and 'about:blank', but not file:// and extension pages? The utility of exposing a context menu entry on those two about pages and not on file pages isn't immediately obvious to me.

[erosman]

one of the problems that you're looking to solve is that you don't want to show context menus on pages in situations where the extension cannot provide its features.

Exactly ...

@erosman, can you provide more context on the scenario you described where you wanted to provide a context menu on 'about:newtab' and 'about:blank', but not file:// and extension pages?

FoxyProxy has a Tab Proxy feature which similar to Firefox containers, relates to a tab and is tied to its ID.
The feature is also added as a context-menu (in next version) and it is useful to limit the pages that the context-menu should appear on.

For the purpose of proxying, it is impractical to have the menu on file:// and moz-extension: pages (which includes toolbar popup where context-menu is seldom used), as well as other about: pages.

See also:
Setting proxy for new tab in Firefox

[xeenon]

I recently needed to limit the context-menu to ['http://*/*', 'https://*/*','about:newtab', 'about:blank'].

I think that allowing explicit 'about:blank' strings would be safer than a blanket about:* pattern:

I agree about:* would not be wise. about:blank and about:srcdoc are the only cross-browser URLs too. I would only be supportive of those two explicit URLs.