1008165 - Duplicated and non-working access keys for in-content preferences

Status: VERIFIED FIXED

(Firefox :: Settings UI, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Today i looked at the inline preferences (about:preferences) and have seen that some of access keys do not work. By raw inspection those are:

* General - Startup - When Aurora starts (s)
* General - Tabs - Warn me when open multiple tabs... (o - already used by Browse)
* General - Tabs - When I open a link in a new tab... (s - already used by Aurora starts)

* Privacy - Tracking - Tell sites ... (t)
* Privacy - History - Clear History - Settings (t - used by tell sites)


Maybe you also want to change the following because they do not meet the guidelines for access keys:

* Advanced - certificates - Ask me every time (i)

There may be other too. Axel could point out the guidelines.

Comment 1

[Axel Hecht [:Pike]]

https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Tutorial/Keyboard_Shortcuts has the guidelines we have, they're not really xul-specific, despite hosted as part of the xul tutorial.

Comment 2

[Jean-Bernard Marcon]

No duplicate accesskey here on my layout, but no accesskey is working. Every accesskey is broken. Should I file a separate bug?

Mozilla/5.0 (X11; Linux i686; rv:32.0) Gecko/20100101 Firefox/32.0

Comment 3

[Dão Gottwald [:dao]]

(In reply to Jean-Bernard Marcon from comment #2)
> No duplicate accesskey here on my layout, but no accesskey is working. Every
> accesskey is broken. Should I file a separate bug?
> 
> Mozilla/5.0 (X11; Linux i686; rv:32.0) Gecko/20100101 Firefox/32.0

You're likely not using the right modifier keys: Alt+Shift.

Comment 4

[Jean-Bernard Marcon]

(In reply to Dão Gottwald [:dao] from comment #3)
> (In reply to Jean-Bernard Marcon from comment #2)
> > No duplicate accesskey here on my layout, but no accesskey is working. Every
> > accesskey is broken. Should I file a separate bug?
> > 
> > Mozilla/5.0 (X11; Linux i686; rv:32.0) Gecko/20100101 Firefox/32.0
> 
> You're likely not using the right modifier keys: Alt+Shift.

Your are right, thanks. But what is the idea of having this new added modifier? I assume previous accesskeys were available with Alt+letter only.

Comment 5

[Francesco Lodolo [:flod]]

(In reply to Jean-Bernard Marcon from comment #4)
> Your are right, thanks. But what is the idea of having this new added
> modifier? I assume previous accesskeys were available with Alt+letter only.

That's not an added modifier, it's the one used for shortcuts in web pages.

Personally, I always change it to use just CTRL (2)
http://kb.mozillazine.org/Ui.key.contentAccess

Comment 6

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

To fix this bug, someone will need to find new accesskeys that do not conflict with the other accesskeys. They will also need to update the accesskey IDs so that other localizers will know to update their own accesskeys which may also be in conflict now that the Tabs and General panes were merged.

Richard, would you like to fix this?

Comment 7

[Axel Hecht [:Pike]]

Please don't bump accesskey IDs, the conflicts in en-US don't need to have anything to do with those in localizations.

I'm wondering, do the preference dialog mozmill tests for l10n still work with the new UI?

Comment 8

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

(In reply to Axel Hecht [:Pike] from comment #7)
> Please don't bump accesskey IDs, the conflicts in en-US don't need to have
> anything to do with those in localizations.

OK, sounds good.

> I'm wondering, do the preference dialog mozmill tests for l10n still work
> with the new UI?

Andrew, can you answer this or redirect to someone who may know the answer?

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to Axel Hecht [:Pike] from comment #7)
> I'm wondering, do the preference dialog mozmill tests for l10n still work
> with the new UI?

No, we have to partly rewrite those which is covered by bug 1005811.

Comment 10

[Richard Marti (:Paenglab)]

Attachment: accessKeys.patch

I've added a patch as a proposeal. What do you think about it?

* General - Tabs - Warn me when open multiple tabs... (using 'd' - because of slows _d_own. The no more used 'w' could also work for Warn me _w_hen opening...).

* General - Tabs - When I open a link in a new tab... (using 'I' - this could make sense because _I_ open a tab).

* Privacy - History - Clear History - Settings (leave it on 't') but change

* Privacy - Tracking - Tell sites that I want to be tracked (to 'w' - for I _w_ant to be tracked like the previous I do _n_ot want...). This needs a change of

* Privacy - History - Nightly will: ... (to 'i' - this will use the i of Nightly and Firefox, on Aurora the i of will)

* For Advanced Certificates I changed a lot to match the main meaning of the sentences/words:
 - _S_elect one automatically (S)
 - _A_sk me every time (A)
 - View _C_ertificates (C)
 - Security _D_evices (D)
Not changed _V_alidation (V) as it's already inline with my changes.
This is a lot of changes here but I think it makes sense to be more descriptive.

Comment 11

[Dão Gottwald [:dao]]

(In reply to Axel Hecht [:Pike] from comment #7)
> Please don't bump accesskey IDs, the conflicts in en-US don't need to have
> anything to do with those in localizations.

Bug 767313 moved elements including their access keys into a different context. It is very likely that this created conflicts in other locales.

Comment 12

[Axel Hecht [:Pike]]

Comment on attachment 8430670 [details] [diff] [review]
accessKeys.patch

Review of attachment 8430670 [details] [diff] [review]:
-----------------------------------------------------------------

https://developer.mozilla.org/en-US/docs/XUL_Accesskey_FAQ_and_Policies states that keys like 'i' or 'I' are actually discouraged. Both are among our choices here, so maybe we can give this another pass.

Comment 13

[Richard Marti (:Paenglab)]

Attachment: accessKeys.patch

Okay, I'm proposing now:
General pane
* Don’t load tabs _u_ntil selected (u instead of l. With this the underline is also longer).
* W_h_en I open a link in a new tab, switch to it immediately (the h is the second letter in this sentence and is fast to recognize).

Privacy pane
* Tell sites t_h_at I want to be tracked (h instead of the t).

Comment 14

[Axel Hecht [:Pike]]

Comment on attachment 8432688 [details] [diff] [review]
accessKeys.patch

Review of attachment 8432688 [details] [diff] [review]:
-----------------------------------------------------------------

policy-wise and technically, this seems to be OK.

I'll leave the review of the actual choices of accesskeys to someone that's fluent in the current prefwindow.

Comment 15

[Richard Marti (:Paenglab)]

Comment on attachment 8432688 [details] [diff] [review]
accessKeys.patch

Thanks, I'll spam Jared again ;)

Comment 16

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

Comment on attachment 8432688 [details] [diff] [review]
accessKeys.patch

Review of attachment 8432688 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks!

Comment 17

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/fx-team/rev/b05b978bdaf6

Comment 18

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/b05b978bdaf6

Comment 19

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Looks all fine with Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0 ID:20140619030203 CSet: f78e532e8a10

I will file a follow-up bug so we can also enhance the access keys for the Sync pane.