Open Bug 1370735 Opened 7 years ago Updated 1 year ago

Insert context menu in a consistent order

Categories

(WebExtensions :: General, enhancement, P3)

Product:
WebExtensions
Component:
General
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: andy+bugzilla, Unassigned)

References

Details

(Whiteboard: [design-decision-needed])

Attachments

(2 files)

Sidebar selection menu.png
(deleted), image/png
Details
Tab context menu.png
(deleted), image/png
Details
This is being forked off of bug 1325758 comment 6. If possible it would be nice to get the context menus inserted in a consistent order. Currently I'm assuming its based on when chrome.contextMenus.create gets called by the add-on. Perhaps we could make it so its sorted on the add-on installation order. Alphabetically is all well and good until you go to different locales.
> Currently I'm assuming its based on when chrome.contextMenus.create gets > called by the add-on. I believe it's even weirder, based on the *first time* .create() is called by the addon since browser startup. > Perhaps we could make it so its sorted on the add-on installation order. > Alphabetically is all well and good until you go to different locales. Alphabetically is still consistent in any locale, so IMO it's is a good solution if we want to go that way. We might wanna align what we use here with the Jazz thing. In any case, UX would probably have something to say here.
As of right now, it's a mess as you don't know what will load first during startup. It would be nicer it developers / users can insert separators. This should be P3.
Mike Conca and I had a discussion about this and related context-menu issues at the Austin All Hands. Based on that discussion, which was encouraging, I am hopeful that we can make progress on these issues. One of the use cases we discussed was an extension which might like to make additional search engines (beyond the default) available in the context menu, like Context Search. I use such an extension very heavily, to look up terms I encounter on Wikipedia, Wiktionary, etc., and I imagine there are a number of other users who do as well. There are several issues impeding the user experience with such an extension currently: - The insertion point of the context menu is currently unpredictable (i.e., this bug). This inhibits the development of muscle memory to use a particular entry. - Even if the insertion order is made predictable, always adding extension entries at the bottom can result in the set of context menu entries not being in a logical / consistent order. For example, a search-related context menu entry would make much more sense next to the existing "search with the default search engine" entry, than at the bottom of the menu. One idea brought up during the discussion was giving each "section" of the context menu (the groups separated by horizontal bars) a name, and allowing extensions to choose a section to be inserted into. - The limitation that one extension can only have one top-level context menu entry means that either: a) the individual search engines are in a submenu (even worse for muscle memory since you now have to hover, pause, move the mouse precisely sideways, etc.); or b) you install a separate extension for every search engine you want there. It would be nice not to have to resort to such workarounds. Mike, I am needinfo-ing you as requested in Austin. Please let me know if there is anything I can do to help make progress / achieve a resolution on these issues. Thanks!
Flags: needinfo?(mconca)
This bug seems to have stalled, can we get an update?
This feature was discussed last week. Without committing to a specific Firefox release, I feel confident saying we will be raising the priority of this request and will address it soon.
Flags: needinfo?(mconca)
Priority: P5 → P3
Blocks: 1466876
Product: Toolkit → WebExtensions
Assignee: nobody → rob
Status: NEW → ASSIGNED
Iteration: --- → 63.2 - July 23
Iteration: 63.2 - July 23 → 63.3 - Aug 6
(In reply to Botond Ballo [:botond] from comment #3) > - The insertion point of the context menu is currently > unpredictable (i.e., this bug). This inhibits the > development of muscle memory to use a particular > entry. Extensions can now use access keys in menus to help with key-based muscle memory: bug 1320462 We can fix a consistent order for pre-registered menu items, but dynamically added menu items will still be appended at the end to minimize the number of shifting menu items. Just for clarity: menu items are created in two passes: - Extensions can register menu items before the menu is shown via menus.create. - Extensions can dynamically add/modify menu items after the menu is shown with menus.refresh. Items of the second type can be added after an unknown delay, so forcing them to follow the same rules as menus of the first type could result in a deteriorated UX. > - Even if the insertion order is made predictable, > always adding extension entries at the bottom can > result in the set of context menu entries not being > in a logical / consistent order. > > For example, a search-related context menu entry > would make much more sense next to the existing > "search with the default search engine" entry, than > at the bottom of the menu. > > One idea brought up during the discussion was giving > each "section" of the context menu (the groups > separated by horizontal bars) a name, and allowing > extensions to choose a section to be inserted into. Bug 1325758 requested the ability to specify a specific position, but that was denied. > - The limitation that one extension can only have one > top-level context menu entry means that either: > > a) the individual search engines are in a submenu > (even worse for muscle memory since you now have > to hover, pause, move the mouse precisely sideways, > etc.); or > > b) you install a separate extension for every search > engine you want there. It would be nice not to have > to resort to such workarounds. Bug 1294429 asked for this, but that was denied too.
Blocks: 1294429
See Also: → https://bugzilla.mozilla.org/show_bug.cgi?id=1325758
Mike - see comment 3, comment 5 and comment 6. Is this bug only about ensuring consistent ordering of menu items, or do we also want to revisit bug 1325758 and/or bug 1294429 ?
Flags: needinfo?(mconca)
(In reply to Rob Wu [:robwu] from comment #6) > (In reply to Botond Ballo [:botond] from comment #3) > > - The insertion point of the context menu is currently > > unpredictable (i.e., this bug). This inhibits the > > development of muscle memory to use a particular > > entry. > > Extensions can now use access keys in menus to help with key-based muscle > memory: bug 1320462 Thanks, that's good to know. That said, I don't find this to be a satisfying solution, because previously activating a context menu was a mouse-only workflow, and had use cases in situations where e.g. you're just reading an article and want to look up something, and you may not be using the keyboard at all. > > - Even if the insertion order is made predictable, > > always adding extension entries at the bottom can > > result in the set of context menu entries not being > > in a logical / consistent order. > > > > For example, a search-related context menu entry > > would make much more sense next to the existing > > "search with the default search engine" entry, than > > at the bottom of the menu. > > > > One idea brought up during the discussion was giving > > each "section" of the context menu (the groups > > separated by horizontal bars) a name, and allowing > > extensions to choose a section to be inserted into. > > Bug 1325758 requested the ability to specify a specific position, but that > was denied. Yup, I am aware. Based on my discussion with Mike in Austin (which happened after bug 1325758 was marked as wontfix), I became hopeful that the decision could perhaps be revisited, even if just partially. In particular, I'm hopeful for a compromise approach where we don't allow specifying a _precise_ position, but we come up with names for the different "sections" of the context menu (the groups of commands separated by a horizontal separator line), and allow an extension to specify a section for new items it adds (which would then be inserted at the bottom of the section). This would allow preserving invariants like "Inspect Element is always the bottom entry", and grouping e.g. search-related extension items together with the existing "Search <default search engine>" item. > > - The limitation that one extension can only have one > > top-level context menu entry means that either: > > > > a) the individual search engines are in a submenu > > (even worse for muscle memory since you now have > > to hover, pause, move the mouse precisely sideways, > > etc.); or > > > > b) you install a separate extension for every search > > engine you want there. It would be nice not to have > > to resort to such workarounds. > > Bug 1294429 asked for this, but that was denied too. With the hindsight of some usage experience, I'm less concerned about this one - option (b) has worked fine for me as a workaround in practice. It would still be nice to lift the restriction, but I think the previous issue (specifying a group to insert into) is the more important one.
(In reply to Botond Ballo [:botond] from comment #8) > > Yup, I am aware. Based on my discussion with Mike in Austin (which happened > after bug 1325758 was marked as wontfix), I became hopeful that the decision > could perhaps be revisited, even if just partially. > > In particular, I'm hopeful for a compromise approach where we don't allow > specifying a _precise_ position, but we come up with names for the different > "sections" of the context menu (the groups of commands separated by a > horizontal separator line), and allow an extension to specify a section for > new items it adds (which would then be inserted at the bottom of the > section). Any reason/dogma against letting the user customize the position of context menu entries?
(In reply to avada from comment #9) > Any reason/dogma against letting the user customize the position of context > menu entries? I would be fine with that too. Basically, any approach that avoids extensions' context menu entries permanently being stuck at the bottom of the context menu, would make me happy.
(In reply to avada from comment #9) > Any reason/dogma against letting the user customize the position of context > menu entries? That seems perfect to me! The user has full control on where to place the context menu items, organising them as he or she wants.
This bug is about consistent ordering, and the primary driver is accessability. While the Web Content Accessibility Guidelines (WCAG) [1] apply to web content, we try to follow them for product design as well. And a fundamental tenet of the guidelines is predictability so that navigation items appear in the same order unless explicitly changed by the user. Regarding specifying the exact (or even relative) position of a menu item, the decision was made to not let extensions do this, and the reasoning is explained in bug 1325758. I do agree that letting users customize the order of menu items would be nice, but that is beyond the scope of extensions. Please file a separate bug against the Firefox frontend for that request. Finally, the use case for specifying multiple top-level items seemed to center around search. Comment 8 sounds like this isn't much of an issue anymore, and I suspect that the addition of the browser.search.search() API may make this even less important for this use case. [1] https://www.w3.org/WAI/standards-guidelines/wcag/
Flags: needinfo?(mconca)
(In reply to Mike Conca [:mconca] from comment #12) > Regarding specifying the exact (or even relative) position of a menu item, > the decision was made to not let extensions do this, and the reasoning is > explained in bug 1325758. Reviewing the concerns described in bug 1325758, it seems to me that almost all are addressed by Shane's "logical grouping" idea described in bug 1325758 comment 19. The only outstanding concern is perhaps that addons will fight for the "top spot", but I think we can address that by setting aside the topmost grouping (which contains the "Copy" and "Select All" menu items when text is selected) for built-in commands only. I'm really hoping that this decision can be revisited given the user feedback we've had in bug 1325758 and this bug. > I do agree that letting users customize the order > of menu items would be nice, but that is beyond the scope of extensions. > Please file a separate bug against the Firefox frontend for that request. Unfortunately, such a Firefox frontend bug has been filed (bug 1385202), and closed as "wontfix" with the explanation that "I don't think that's something we're ever likely to implement given the cost/benefit and other priorities". That makes it all the more desirable to have a solution on the WebExtension side.
Ensuring consistent order is relatively simple, and at the same time not having that much impact. I'll revisit this bug around the 64 branch date.
Iteration: 63.3 - Aug 6 → 65.1 (Nov 2)

This is a bit fraught:

  • existing habit/workflows are changing for no good benefit
  • enforcing an arbitrary order seems of dubious use
  • allowing developers to specify seems potentially detrimental to the end user

Alphabetical seems to be the only reasonable (and consistent) change here, as noted in #c1. Added whiteboard and NI Asa for thumbsup/down on that from an accessibility standpoint and if we should up this from P3.

No longer blocks: 1466876
Whiteboard: triaged → [design-decision-needed]
Flags: needinfo?(asa)

Asa, having a consistent order for extension context menu items seems like an accessibility issue (see comment 12) but I wanted to get your take on this feature request. Thanks.

(In reply to Mike Conca [:mconca] from comment #16)

Asa, having a consistent order for extension context menu items seems like an accessibility issue (see comment 12) but I wanted to get your take on this feature request. Thanks.

I've read the background and I think context menu items shifting is a general user experience issue negatively affecting all users of context menus that is probably exacerbated for users with certain disabilities. I'd like to see what UX has to say about what the right thing is for all of our users -- ideally taking into account that menu items unexpectedly changing position may have a disproportionate impact on accessibility. I've ni'd Emanuela for her input.

Flags: needinfo?(asa) → needinfo?(emanuela)

As it seems some bugs are being closed cause "there has been very little interest" on them i want to confirm that i'm still interested on this bug.

With yet another unnecessary context menu encapsulation in FF78 it would be nice, when this bug would get a fix finally.

If an user wants to install an addon which adds an menu item at some specific position there is probably a good reason for it or the user wouldn't install that addon.

Asa, if you are worry that general user experience is affected for all users, then this is already the case now. Also the users which are not satisfied with the current strategy are below your all users.

"unexpectedly changing position may have a disproportionate impact on accessibility" - This is the case for the forced submenus with more as one entry but nobody is worry about that.

If this all is such a big problem, why does Mozilla not offer in the options let us say a general config page for all available context menu entries? You could show a table with all entries and assign a ordinal number. Then let the user change the ordinal number. Or you show the entries and let the user arrange them by drag and drop or whatever.

So no addon developer can decide the position and everyone can configure it. The same place could be used to configure if a submenu is showed or not for more of 1 entry.

If this all is such a big problem, why does Mozilla not offer in the options let us say a general config page for all available context menu entries? You could show a table with all entries and assign a ordinal number. Then let the user change the ordinal number. Or you show the entries and let the user arrange them by drag and drop or whatever.

This is easier said than done.

I think that the easiest solution for this bug is to not have any UI for this functionality, but possibly offer a preference so that users can use about:config to specify the preferred order for extension menu items.
I think that it may already be possible to get a predictable/fixed menu order using userChrome.css, e.g. as shown at https://github.com/Rob--W/bookmark-container-tab/issues/4

Assignee: rob → nobody
Status: ASSIGNED → NEW
Iteration: 65.1 - Nov 2 → ---
Flags: needinfo?(emanuela)
Severity: normal → S3
Duplicate of this bug: 1808023
Attached image Sidebar selection menu.png (deleted) —

Also, the sidebar menu is affected too.

Attached image Tab context menu.png (deleted) —

I will also attach the tab context menu screenshot, because it is affected too.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: