Closed
Bug 1416839
Opened 6 years ago
Closed 6 years ago
Restrict context menus from showing up in the sidebar
Categories
(WebExtensions :: Frontend, enhancement, P2)
WebExtensions
Frontend
Tracking
(firefox64 fixed)
Tracking | Status | |
---|---|---|
firefox64 | --- | fixed |
People
(Reporter: andy+bugzilla, Assigned: robwu)
References
(Blocks 1 open bug)
Details
(Keywords: dev-doc-complete)
Attachments
(1 file)
Currently if you set a context menu to appear on a page or a HTML element (eg: link), they also appear in the sidebar context menus. In WebExtensions its likely that the sidebar is different from the content area and it would be nice if we could find a way to scope context menus to just one of those areas.
Reporter | ||
Comment 1•6 years ago
|
||
See also: https://github.com/mozilla/notes/issues/390
Comment 2•6 years ago
|
||
This is slightly different than bug 1367160, but not much. Doing this may actually lay the groundwork for 1367160.
See Also: → 1367160
Reporter | ||
Updated•6 years ago
|
Priority: -- → P2
Comment 3•6 years ago
|
||
Upon looking at this again, I'm somewhat ambivalent as to whether we should restrict the menus this way. On one hand, isolating extensions from each other is probably the right thing to do. OTOH, an extension adding a context menu to the sidebar to do something new to another extension providing a tab manager could be nice. Thoughts?
Flags: needinfo?(mconca)
Comment 4•6 years ago
|
||
Can we add a new menus.ContextType of "sidebar" that specifically allows extensions to declare if they want to appear in the sidebar context menu? Extensions that implement a sidebar could declare it along with other ContextTypes (like Image, Link, Page, etc.) to indicate they want to be shown when those elements are clicked *only* in the sidebar. Similarly, specifying Image, Link, Page, etc. types without the "sidebar" type means an extension wants to be shown for those elements on normal pages and specifically *not* in the sidebar. This would help out Multi-Account Containers, for example. This seems like it would provide maximum flexibility for extensions to "do the right thing" in each case. We could say that specifying the "sidebar" type by itself has no meaning and that it must be combined with other types. For compatibility, the "all" type should probably still imply that the context menu will be shown for all elements in normal pages and the sidebar.
Flags: needinfo?(mconca)
Comment 5•6 years ago
|
||
(In reply to Mike Conca [:mconca] (Denver, CO, USA UTC-6) from comment #4) > Can we add a new menus.ContextType of "sidebar" We have a bug for that (and I should finish it). Bug 1389387. The question in this bug is about whether we allow a context menu from extension B to show up in a panel owned by extension A.
Comment 6•6 years ago
|
||
(In reply to Shane Caraveo (:mixedpuppy) from comment #5) > (In reply to Mike Conca [:mconca] (Denver, CO, USA UTC-6) from comment #4) > > Can we add a new menus.ContextType of "sidebar" > > We have a bug for that (and I should finish it). Bug 1389387. Hey, look, exactly what I was describing. Thanks! > The question in this bug is about whether we allow a context menu from > extension B to show up in a panel owned by extension A. That is not how I read the title and description of this bug; I latched onto the github bug comment that MAC "has no ability to say don't appear in a sidebar." Hence, my comment 4. If the question is the one you posed above, then YES, I think we definitely want to allow context menus from B to show up in a panel owned by A. There are all kinds of useful features provided by extensions that still make sense in sidebars (language translators, 3rd party search, wiki links, bookmarking, tagging, etc). If A wants to restrict what context menus are shown, bug 1367160 is probably a better way to do it. Perhaps under that bug, we can offer a way to not only restrict what default context menu items are shown, but also if context menu items from other extensions should be shown.
Updated•6 years ago
|
Product: Toolkit → WebExtensions
Assignee | ||
Updated•6 years ago
|
Assignee: nobody → rob
Status: NEW → ASSIGNED
Iteration: --- → 63.2 - July 23
Assignee | ||
Updated•6 years ago
|
Iteration: 63.2 - July 23 → 63.3 - Aug 6
Assignee | ||
Updated•6 years ago
|
Status: ASSIGNED → RESOLVED
Iteration: 63.3 - Aug 6 → ---
Closed: 6 years ago
Resolution: --- → DUPLICATE
Assignee | ||
Updated•6 years ago
|
Status: RESOLVED → REOPENED
Iteration: --- → 64.2 (Sep 28)
Resolution: DUPLICATE → ---
Assignee | ||
Comment 8•6 years ago
|
||
- Support viewTypes property in menus.create / menus.update. - Add info.viewType to menus.onShown / menus.onClicked event. - This "viewType" reuses the existing extension.ViewType enum, which is a "tab", "popup" (pageAction/browserAction) or "sidebar".
Comment 9•6 years ago
|
||
Comment on attachment 9010268 [details] Bug 1416839 - Add viewType/viewTypes to menus API Shane Caraveo (:mixedpuppy) has approved the revision.
Attachment #9010268 -
Flags: review+
Comment 10•6 years ago
|
||
Pushed by rob@robwu.nl: https://hg.mozilla.org/integration/autoland/rev/6341cb6ae607 Add viewType/viewTypes to menus API r=mixedpuppy
Comment 11•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/6341cb6ae607
Status: REOPENED → RESOLVED
Closed: 6 years ago → 6 years ago
status-firefox64:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
Updated•6 years ago
|
Keywords: dev-doc-needed
Comment 12•5 years ago
|
||
Note to docs team: I've added a note to cover this in the Fx64 rel notes: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/64#Changes_for_add-on_developers It looks like comment 8 of this bug states pretty clearly what needs to be done.
Assignee | ||
Comment 13•5 years ago
|
||
Added viewTypes
to https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/menus/create
viewType
was already listed at https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/menus/OnClickData
Keywords: dev-doc-needed → dev-doc-complete
You need to log in
before you can comment on or make changes to this bug.
Description
•