Feature Request: [ContextMenus] Include <canvas>s in the "page" ContextType (or it's own ContextType)

[hicallmeal]

Currently, the only way for a ContextMenu item to appear on a <canvas> click, is with the ["all"] ContextType.
(From testing on Firefox and Chromium).

This adds menu items to places they aren't needed (e.g. Popup), leading to potential user confusion.

An example use case might be a "Resize this image" menu item, which would ordinarily need ["image", "page" (SVGs)] ContextTypes, but "all" for canvases (for cases where a canvas has an image).

My request/proposal is <canvas> inclusion in the "page" context, or it's own (if there are security concerns).

[maxnikulin]

I do not need namely CANVAS: "canvas" in contextMenus.ContextType, but related Firefox menus extensions look promising. Unfortunately my reading of #188 is that Chrome and Safari teams are against of features in that spirit.

A more general idea was posted to the chromium-extensions mailing list (likely by @robbi73): CSS selectors to specify HTML elements meaningful for context menu actions, see Why not brush up the contextMenu API a little? Sun, 2 Jul 2023 14:52:27 -0700 (PDT).

To avoid context menu item in extension action popups and side panels, there is a workaround, see Simeon Vincent. Re: [crx] Context menu appears on the pages of other extensions. It's a normal behaviour? Thu, 6 Jul 2023 15:07:39 -0700:

documentUrlPatterns value to match *://*/* ... will only match against HTTP and HTTPS pages

This approach does not allow however an opposite condition: to limit a menu items to side panels and action popups, but to avoid it in any regular tabs. Firefox has additional CreateProperties.viewTypes field paired with onClickData.viewType. Possible values: extension.ViewType. The "tab" value should prevent menu item appearance in action popups.

A PDF file may be a more tricky case for approaches other than CSS selector. Perhaps simple documentUrlPatterns is not enough in the case of an <iframe src="https://..."> embedded into a side panel.

Notice that context menu action for <canvas> element assumes scripting, but the activeTab permission is not enough in the case of a cross-origin frame. For accidental actions on random sites an extension must request either for rather dangerous <all_urls> or for more limited, by still permanent host permissions.

[xeenon]

I'm supportive of a canvas type. I don't think it should count as page.

[maxnikulin]

I'm supportive of a canvas type.

Do you plan to add some fields to OnClickData specific to canvas? From my point of view "canvas" scope is rather narrow and adding it may cause requests to add more HTML elements to context types. Unfortunately I can not estimate implementation and maintenance cost of a more flexible selector.

Just to express it explicitly: this issue depends on #716.

(Unfortunately compatibility data for onClickData on MDN are incomplete, so it is not obvious what fraction of extensions in respect to Chrome is supported by Safari. E.g. linkText is present, but viewType is not.)

[hicallmeal]

documentUrlPatterns value to match *://*/* ... will only match against HTTP and HTTPS pages

@maxnikulin Admittedly this hadn't occured to me, in the context of this issue, as work-around, so I'm grateful you've mentioned it!

With regards to your second comment, when I created this issue I had treated/viewed it as unrelated to #716, as they were things I encountered that both happened to fall within the ContextMenus namespace.

But I can see what you're saying; I'd also love to see support for extended onClickData properties, but I would consider that mostly out of scope for this issue, especially when taking in to account the issue Fregante linked and comment by Rob Wu, in #716.

[Rob--W]

I'm not convinced of the need to add "canvas" in the contextMenus API. The contextMenus.onClicked event itself would not see much useful data. I'd be more supportive of a CSS selector method.

Note that in Firefox, we have also implemented the menus.onShown / menus.onHidden events, and together with the menus.refresh() and menus.getTargetElement() methods, this offers a very general way to allow extensions to dynamically update context menus for whatever use case extension developers can come up with.

[maxnikulin]

Note that in Firefox, we have also implemented the menus.onShown / menus.onHidden events, and together with the menus.refresh() and menus.getTargetElement() methods, this offers a very general way to allow extensions to dynamically update context menus for whatever use case extension developers can come up with.

These methods should allow to hide menu items if the frame is not reachable by content scripts (tabId = -1 for side panel or action popup, url is not exposed on first click) in the absence of onClickData.viewType. I described above <iframe src="https://..."> case matched by documentUrlPatterns: *://*/*.

In my opinion, running context menus must not require <all_urls> or host permissions. It should be enough to request activeTab (or not yet existing contextMenus.activeFrame for cross-origin frames). Firefox-128 properly grants activeTab when a menu item is clicked, so onShown may not have permissions to execute a content script yet. It would be a surprise for users if some extension runs scripts before its menu item is clicked.

menus.onShown and menus.refresh are not substitute for more precise declarative specification of menu item context.