-
Notifications
You must be signed in to change notification settings - Fork 56
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
Feature Request: [ContextMenus] Include <canvas>s in the "page" ContextType (or it's own ContextType) #717
Comments
I do not need namely 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:
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 A PDF file may be a more tricky case for approaches other than CSS selector. Perhaps simple Notice that context menu action for |
I'm supportive of a |
Do you plan to add some fields to Just to express it explicitly: this issue depends on #716. (Unfortunately compatibility data for |
@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 |
I'm not convinced of the need to add "canvas" in the Note that in Firefox, we have also implemented the |
These methods should allow to hide menu items if the frame is not reachable by content scripts ( In my opinion, running context menus must not require
|
Just brain-storming, since I have no details related to reporter's case: current canvas image might be exposed as |
These events are not in content scripts but in the extension context, e.g. background script. If extensions want to they can hide menu items. Here is an example of dynamic context menu toggling without using any content scripts: https://github.com/Rob--W/bookmark-container-tab/blob/master/background.js
For common cases it would make sense to not require it. The contextMenus.onShown event does not grant activeTab, contextMenus.onClicked does. In the reporter's use case, I think that the extension cannot meaningfully act on the context menu event without host permissions.
I'm in favor of declarative properties when they are more generally useful. We cannot add a declarative member for every single niche use case though, because that increases the complexity of the API.
This is not feasible. A canvas does not have a URL. And if you are thinking of generating a Another issue with exposing this blindly is that a canvas can be tainted with cross-origin data. Exposing the content would basically require |
I agree with pretty much all the points outlined here and in the recent meeting. I apologise, I really should have initially provided a better example (specifically, my use case). So, in my case, I have a context menu item which is essentially "Scan this QR Code", which on click, obtains the QR image and decodes it. Currently that means using the "image" and "page" context type (great to use), but "all" for canvas. And as noted initially, that adds the menu item to places it's not needed and could cause confusion. That's what lead me to suggest it be included in "page", as it's simply another element. I included the seperate type in case that was preferred by vendors On some of the points raised -
I should also say that this is admittedly quite reliant on #716, so I'm happy to pause discussion here until that is concluded. |
I feel some sort of confusion, but I can not figure out its source. In Firefox it is possible to implement a context menu item visible only for
However in the case of an iframe embedded into a side panel or an action popup A more serious issue, from my point of view, is that the extension must require the Even if CSS context matching or "canvas" type was implemented, |
@maxnikulin (This has come up in some testing) I just wanted to note, in reference to
I misspoke in regards to this -
I actually meant contextMenu clicking the browser action itself (i.e. the "action" ContextType equivalent), not Popup or general extension pages. I generally agree with your last comment. |
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).
The text was updated successfully, but these errors were encountered: