Insert context menu in a consistent order

ASSIGNED
Assigned to

Status

P3
normal
ASSIGNED
2 years ago
11 days ago

People

(Reporter: andy+bugzilla, Assigned: robwu)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: triaged)

(Reporter)

Description

2 years ago
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.

Comment 2

a year ago
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?

Comment 5

7 months ago
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

Updated

5 months ago
Blocks: 1466876

Updated

5 months ago
Product: Toolkit → WebExtensions
(Assignee)

Updated

4 months ago
Assignee: nobody → rob
Status: NEW → ASSIGNED
Iteration: --- → 63.2 - July 23
(Assignee)

Updated

4 months ago
Iteration: 63.2 - July 23 → 63.3 - Aug 6
(Assignee)

Comment 6

2 months ago
(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: → bug 1325758
(Assignee)

Comment 7

2 months ago
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.

Comment 9

2 months ago
(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.

Comment 12

2 months ago
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.
(Assignee)

Comment 14

a month ago
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)
You need to log in before you can comment on or make changes to this bug.