1044214 - Restore access keys to new Context Menu

Status: NEW

(Firefox :: Keyboard Navigation, defect)

Description

[Sevaan Franks [:sevaan]]

We've added icon navigation to our context menus in Firefox, but in doing so have removed some of the keyboard access keys.

Let's restore:

B - Back
F - Forward
R/S - Refresh
M - Bookmark

Comment 1

[Dão Gottwald [:dao]]

There are several reasons why this is a bad idea; this has been discussed at length when implementing bug 1000513.

Comment 2

[Sevaan Franks [:sevaan]]

Hi Dao,

So I've read through the bug and am still not clear on why it's a bad idea.

I understand that access keys should be discoverable and that they are not with the new icons...but access keys have never been discoverable on a Mac and we still had them implemented: http://cl.ly/image/082h0j030O1E

We have users who are used to using access keys, so it doesn't hurt to keep them active for our users who use them with muscle memory...why break their flow?

Comment 3

[Dão Gottwald [:dao]]

I'm not sure that this is all documented in the bug, some of this was possibly discussed only on IRC.

Off the top of my head, I think the worst problem was that hidden access keys create problems for content and add-on provided context menu items. They may not have access keys (I think content provided items never do), in which case the first letter acts the implied access key, unless it's already taken as some other item's explicit access key. But this is unpredictable if there are hidden explicit access keys.

Are the specified access keys actually effective on OS X or do we just use the label's first letter as the implied access key there? The former would be pretty bad from a user's point of view if a specified access key was somewhere in the middle of the label, which is impossible to predict if the access keys aren't visible. If this is the case then I don't think what we're doing on OS X should be our role model for Windows and Linux.

Comment 6

[P. Mascari]

Simple user input.....I used these access keys all the time on both Mac and PC.  I didn't even realize how much until they were taken away.  Please restore.

Comment 7

[Jared Wein [:jaws] (please needinfo? me)]

Hey Axel, is this something that we could restore on Beta/Aurora/Central by using old values of the l10n repositories? Or would it have to ride the trains like all other l10n changes?

Comment 8

[Francesco Lodolo [:flod]]

Unfortunately it needs to ride the trains. 

Those strings disappeared from l10n repositories a couple of months ago, and there's no such thing as "using old values" (strings need to be added back to repositories).

Comment 9

[:Gijs (he/him)]

(In reply to Francesco Lodolo [:flod] from comment #8)
> Unfortunately it needs to ride the trains. 
> 
> Those strings disappeared from l10n repositories a couple of months ago, and
> there's no such thing as "using old values" (strings need to be added back
> to repositories).

Eh? I mean, the point of source control is pretty much exactly this. We can revert the removal of those strings using the VCS's history. Why wouldn't that be possible?

Comment 10

[Axel Hecht [:Pike]]

I think the UX questions haven't been answered here. How do people that need a11y work this menu, and find out about access keys to begin with?

On the question at hand:

Accesskeys change depending on context. Just because they were good a few releases back doesn't mean they're good today. Also assumes that they've been good back then.

I don't see good use to discuss our l10n tools in this bug. https://blog.mozilla.org/l10n/2011/12/06/future-of-mozilla-l10n-tools/ is what we're suffering from here, and as you can see, we didn't make any progress since 2011. And even if we start making progress, it'll be a at least a year 'til we can harvest the fruit.

Let's work with what we have and let this ride the trains. Once we actually know what to do.

Comment 11

[jaramat]

If you're worried about the access keys' discoverability, just add them to the tooltips:

"Go back one page (B)"
"Go forward one page (F)"
"Reload current page (R)"
"Stop loading this page (S)"
"Bookmark This Page (M)"

in a similar manner to "Inspect Element (Q)".

Oh, and while we're at it, "Bookmark This Page"'s every word starts with a capital letter, while the others do not. Is this a known bug, or should it be reported?

Comment 12

[Mathew Hodson]

Bug 1017580 is the same as this issue, so that bug should be marked as a duplicate of this or vice versa.

Also bug 1017850 currently depends on bug 1000513, but it should block it like this one does.