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)

enhancement

Tracking

(firefox64 fixed)

RESOLVED FIXED
mozilla64
Iteration:
64.2 - Sep 28
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.
This is slightly different than bug 1367160, but not much.  Doing this may actually lay the groundwork for 1367160.
See Also: → 1367160
Priority: -- → P2
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)
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)
(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.
(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.
Product: Toolkit → WebExtensions
Assignee: nobody → rob
Status: NEW → ASSIGNED
Iteration: --- → 63.2 - July 23
Iteration: 63.2 - July 23 → 63.3 - Aug 6
Status: ASSIGNED → RESOLVED
Iteration: 63.3 - Aug 6 → ---
Closed: 6 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → REOPENED
Iteration: --- → 64.2 (Sep 28)
Resolution: DUPLICATE → ---
- 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".
See Also: → 1280347
Comment on attachment 9010268 [details]
Bug 1416839 - Add viewType/viewTypes to menus API

Shane Caraveo (:mixedpuppy) has approved the revision.
Attachment #9010268 - Flags: review+
Pushed by rob@robwu.nl:
https://hg.mozilla.org/integration/autoland/rev/6341cb6ae607
Add viewType/viewTypes to menus API r=mixedpuppy
https://hg.mozilla.org/mozilla-central/rev/6341cb6ae607
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
Flags: qe-verify-
See Also: → 1498896
Keywords: dev-doc-needed
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.
You need to log in before you can comment on or make changes to this bug.