2083997 - auto access key of context menu conflicts

Status: ASSIGNED

(Firefox :: Keyboard Navigation, defect)

Description

[lilydjwg]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:160.0) Gecko/20100101 Firefox/160.0

Steps to reproduce

• Install https://addons.mozilla.org/firefox/addon/single-file/
• On any webpage, select any text
• Right click and press s

Actual results

The search menu item is highlighted but not activated, because SingleFile also has s as its access key.

Expected results

Do not automatically create conflicts. Always use numbers for auto access keys? I don't really know what would be the best solution, but I'm now considering to not install any extension that creates a context menu with an explicit access key and has a name starting with s.

This is regressed by bug 2074182, which claims to fix bug 2073853 but it doesn't: it fixes that some extension menu items don't have access keys, but creates duplicates instead.

Comment 1

[lilydjwg]

creates a context menu with an explicit access key

Oops. I meant "without".

SingleFile ha the option to disable the context menu which works around my problem, but I still have two fs, and below one of them (Format Link) I have five as.

Comment 2

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[BugBot [:suhaib / :marco]]

:dao, since you are the author of the regressor, bug 2074182, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 4

[BugBot [:suhaib / :marco]]

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Comment 5

[Dão Gottwald [:dao]]

(In reply to lilydjwg from comment #0)

The search menu item is highlighted but not activated, because SingleFile also has s as its access key.

Is hitting Enter after s too cumbersome generally, or is the issue muscle memory / realizing that Enter is needed?

I have no strong opinion here. Using numbers only for extension menu items may be a reasonable alternative.

Comment 6

[Dão Gottwald [:dao]]

Analysis of numbers vs. letters for auto-accesskeys:

Numbers

• Microsoft's Win32 UX guidelines require an access key on every menu item and give dynamic items such as a recent-files list numeric access keys, with Paint as the example (Keyboard, Accessibility). The Windows 7 menu guidelines state the same rule (Menus).
• Office, Visual Studio and Notepad++ number their recent-files lists, and MDI apps number their Window menus (&1 Document1).

In each case the app doesn't control the labels, as with extension items in our context menu.

Letters

• KDE's KAcceleratorManager assigns letters automatically to every menu item that lacks one and reassigns them when entries are added to or removed from a QMenu. It scores candidate letters to avoid duplicates, favoring word starts and letters an item already claims (class reference, source). KDE resolves this exact conflict with a different letter, not a number.
• Win32 menus and Chromium's views menus assign nothing. They match an item without a mnemonic by the first character of its label; Chromium's TitleMatchesMnemonic does this only for items without a mnemonic (menu_controller.cc). Duplicates cycle and need Enter.
• Gecko's XULMenuParentElement::FindMenuWithShortcut already does the same first-character match for items without an accesskey. (Bug 2074182 promoted that implicit letter to an explicit one, so it now cycles with our own s where it used to be shadowed by it.) This is not an option here unless we remove all access keys from the context menu, only to arrive at the same behavior the reporter is complaining about.

Trade-offs of numbers for extension items

• They never collide with our letters, which fixes the reported case.
• They aren't mnemonic, and they shift. Which extension items appear depends on the context (selection, link, image), so SingleFile might be 1 in one menu and 2 in another. Windows accepts the same instability for recent files, where the order changes constantly.
• They cap at ten items. A label starting with a digit, which bug 2074182 currently uses as the accesskey, would either lose that or make the numbering skip.

KDE's approach (a free letter from anywhere in the label) keeps keys mnemonic and mostly stable. Our built-in items also vary by context, though, so the chosen letter wouldn't be stable and need a small scorer.

Comment 7

[lilydjwg]

I'm used to select a word or phrase with mouse, right click and press s to search it. It is muscle memory for many years. Also pressing Enter means either to move my right hand from mouse to keyboard (and then move back after that), or use my left to press Enter which is cumbersome.

Comment 8

[Dão Gottwald [:dao]]

Attachment: Bug 2083997 - Number auto-accesskey menu items instead of giving them their label's first letter. r?robwu!,#sidebar-reviewers,#reusable-components-reviewers

Spelling suggestions and dictionaries use auto-accesskey too, so they get numbered as well.

Comment 9

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 2074182

Comment 10

[TechHorse]

Hello, speaking as a pure keyboard user I'd like to say that with access keys consistency is everything for me.

I won't use the access key for a function or list item if sometimes it's one key, sometimes it's another, as I'd be too nervous of inadvertently activating something undesirable or unexpected.

Having a situation where pressing X will activate an item straightaway in some contexts, but it will cycle through shared access key options in another, is significantly, significantly more preferable than the key itself changing between one moment and the next.

Because a consistent key cannot lead to activating unwanted or undesirable functions.

To add a further complication in my personal case, as a visually impaired user, I cannot just glance at the options to see which letter is underlined this time.

But even if I could I would still want access keys and keyboard shortcuts in general to remain consistent, so I can just use them without having to first check for changes.

Just wanted to share some thoughts, thanks.

Comment 11

[TechHorse]

P.S. I do understand that some people have no desire for unused add-on access keys to clash with used built-in ones (or vice versa). But for me the significantly better solution would be to allow the disabling or changing of an access key by the user, rather than having a dynamic system.

Comment 13

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 2074182

Comment 14

[Dão Gottwald [:dao]]

Jamie, comment 10 argues for stable accesskeys over the digits this patch assigns. What's your take on that, and how would you remedy it?

One middle option: an extension item keeps its label's first letter when no other item in the menu uses it, and gets a digit only when the letter is taken. That fixes comment 0 and keeps the letters in bug 2087843, but the keys still change between contexts.