Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Allow globs for the contextMenus API instead of just URL patterns. #583

Open
polywock opened this issue Apr 2, 2024 · 12 comments
Labels
neutral: firefox Not opposed or supportive from Firefox supportive: safari Supportive from Safari

Comments

@polywock
Copy link

polywock commented Apr 2, 2024

The contextMenus API allows for restricting a context menu item to pages that match a URL pattern. I propose also allowing for globs instead of only URL patterns. I wanted to allow users to customize where the context menu is shown, but came to realize that URL patterns makes it difficult to support a contains-like pattern.

browser.contextMenus.create({
    ...,
    documentUrlGlobs: [`*${contains}*`]
})
@github-actions github-actions bot added needs-triage: chrome Chrome needs to assess this issue for the first time needs-triage: firefox Firefox needs to assess this issue for the first time needs-triage: safari Safari needs to assess this issue for the first time labels Apr 2, 2024
@Rob--W
Copy link
Member

Rob--W commented Apr 2, 2024

The example you've shown is the same as a match pattern. Match patterns are already sufficiently expressive to enable "contains" match, in the path or query component of a URL. Do you have a use case where a glob would work but a MatchPattern would not?

Even without any new APIs, it is already possible for extensions to toggle the visibility of context menus, by calling browser.contextMenus.update(menuId, { visible: false }) to hide it, and visible: true to show it again.

Firefox has the contextMenus.onShown event from where you can try to update the context menu based on the contextual information.

Chrome does not support the contextMenus.onShown event; as an alternative you could consider updating the menu based on the focused window and tab (tabs.onUpdated + windows.onFocusChanged). These events are more chatty than contextMenus.onShown though. There is no event to determine the focused iframe (unless you are willing to run a content script everywhere to intercept mouse/contextmenu events, which I would not recommend).

If you are interested in exploring onShown, refresh and visible, here are relevant links:

@polywock
Copy link
Author

polywock commented Apr 2, 2024

I would like to provide a field where the user can provide a URL fragment substring.

Here's a more accurate example of how I plan to use it. This would be an invalid URL pattern, but a valid glob.

browser.contextMenus.create({
    ...,
    documentUrlGlobs: [`*${containsKeyword}*`]
})

@Rob--W
Copy link
Member

Rob--W commented Apr 2, 2024

Your provided use case is already possible with match patterns: *://*/*#*keywordhere*

@polywock
Copy link
Author

polywock commented Apr 2, 2024

My bad. By URL fragment, I meant a substring within any part of the URL

@xeenon
Copy link
Collaborator

xeenon commented Apr 2, 2024

Even without any new APIs, it is already possible for extensions to toggle the visibility of context menus, by calling browser.contextMenus.update(menuId, { visible: false }) to hide it, and visible: true to show it again.

@Rob--W That assumes the extension has access to the URL, which is not always the case (especially in Safari). documentUrlPatterns is a declarative way to allow activeTab extensions to have context menus respond to the current URL in a privacy preserving way.

While Safari does not currently support globs for anything in Web Extensions, I would be supportive of this if we do add support for globs.

@xeenon xeenon added supportive: safari Supportive from Safari and removed needs-triage: safari Safari needs to assess this issue for the first time labels Apr 2, 2024
@xeenon
Copy link
Collaborator

xeenon commented Apr 2, 2024

Side note: I loathe the fact that the documentUrlPatterns property is not documentURLPatterns (with all caps URL). So I'm not super thrilled about adding a second property with similar case.

@tophf
Copy link

tophf commented Apr 2, 2024

documentUrlPatterns property is not documentURLPatterns

FWIW, enforcing camelCase when combining is a widely used convention, nothing criminal.

@tophf
Copy link

tophf commented Apr 2, 2024

What about documentUrlFilter with URL filters used in webNavigation and declarativeContent API? Meaningfully flexible allowing both complex conditions and a simple urlContains to accommodate for the OP's case. It would make sense to add urlGlob anyway to allow things like *foo*bar* without resorting to a slower RegExp via urlMatches.

@Rob--W
Copy link
Member

Rob--W commented Apr 2, 2024

I'd like to see use cases before expanding the API surface.

The original use cases provided thus far can be covered with match patterns.

It may be tempting to "relax" the syntax, by allowing a ln arbitrary glob instead of a "stricter" match pattern as documentUrlPatterns (and targetUrlPatterns), but that is not backwards-compatible. In a match pattern, ? matches a question mark, while in a glob it matches exactly one character.

Conceptually I am not opposed to expanding globs, but only if there are compelling use cases that need it.

@polywock
Copy link
Author

polywock commented Apr 2, 2024

The original use cases provided thus far can be covered with match patterns.

A contains-like pattern can be covered by match patterns, but it's more cumbersome and requires parsing the user's submitted keyword to generate an equivalent match pattern.

Edit: On further thought, a contains-like pattern can't be fully covered because match patterns don't support partial hosts. The host has to be fully defined except for the subdomain.

@hanguokai
Copy link
Member

The previous discussions are all technical and developer-oriented. The real problem is that the author wants users to customize the rules. This means several questions:

  • Are users advanced users who understand technology or ordinary users?
  • Can users accept complex technical rules?

If the target users understand technology (e.g. users are developers), you can use the existing documentUrlPatterns and give users a link to the reference manual. If the target users don't understand technology, you need to design a simple rule for users, for example, only let users custom the domains part of URL.

@polywock
Copy link
Author

polywock commented Apr 4, 2024

@hanguokai Great points! For my case, the latter is the only option. If documentUrlGlobs was supported, I could just throw an input field with a label that says URL contains: and be done with it. The current approach with match patterns requires more thoughtful thinking and effort.

@oliverdunk oliverdunk removed the needs-triage: chrome Chrome needs to assess this issue for the first time label Apr 23, 2024
@Rob--W Rob--W added neutral: firefox Not opposed or supportive from Firefox and removed needs-triage: firefox Firefox needs to assess this issue for the first time labels Apr 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
neutral: firefox Not opposed or supportive from Firefox supportive: safari Supportive from Safari
Projects
None yet
Development

No branches or pull requests

6 participants