Closed Bug 1660234 Opened 4 years ago Closed 3 years ago

Accesskeys in Options don't work when they are used in a label for a radio button

Categories

(Core :: XUL, defect)

Product:
Core
Component:
XUL
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1699284

People

(Reporter: nONoNonO, Unassigned)

Details

With the "new" Options in a tab keyboard navigation already has become more cumbersome, because you now have to press Alt+Shift+accesskey (or whatever combination the user has configured), but now it's not possible anymore to navigate to or past an accesskey used for a label for a radio button.

STR:

  1. Go to Tools > Options > General
  2. Press Alt+Shift+A and verify that focus switches to Advanced under Language and Appearance
  3. Press Alt+Shift+A again and notice that focus doesn't switch to the next label with accesskey A: Always ask you where to save files under Files and Applications

Expected result: pressing Alt+Shift+A again should move focus to the next accesskey item.

If that next item is a radio button, it probably should select the label instead of slecting/activating that radio button,just like it happens when a menuitem has an accesskey that is not unique.

(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #0)

With the "new" Options in a tab

We shipped the in-content prefs in Firefox 38, 5 years ago - is that what you mean, or are you referencing something else?

keyboard navigation already has become more cumbersome, because you now have to press Alt+Shift+accesskey (or whatever combination the user has configured), but now it's not possible anymore to navigate to or past an accesskey used for a label for a radio button.

This seems to imply this has regressed more recently. Is that what you meant? And if so, do you know when?

Severity: -- → S3
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(o.e.ekker)
Priority: -- → P3

Sorry for any ambiguity by using the word "new". I was referring to the incontent prefs, but I first noticed this bug in Thunderbird, where the incontent prefs were first hidden behind a preference and only later enabled by default. It wasn't until I started filing a bug, that I thought of verifying this in Firefox, so I don't know if this wordked in the incontent prefs earlier or if it has been a problem for incontent prefs from the start, but I suspect the latter.

Flags: needinfo?(o.e.ekker)

I debugged this a bit and I think this is a problem with our accesskey handling, rather than markup, so I'm going to move it accordingly.

Specifically, it seems we wouldn't register the inner XUL label from https://searchfox.org/mozilla-central/rev/73a14f1b367948faa571ed2fe5d7eb29460787c1/layout/xul/nsXULLabelFrame.cpp#30-36 , and it's not clear to me if/where we'd register the <radio> element to the event state manager - but it doesn't appear to be happening.

Severity: S3 → --
Component: Preferences → XUL
Priority: P3 → --
Product: Firefox → Core

The severity field is not set for this bug.
:enndeakin, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(enndeakin)
Severity: -- → S3
Flags: needinfo?(enndeakin)

Bug 1699284 improves the focus handling for accesskey a bit, Onno could you try the latest Nightly?

Flags: needinfo?(o.e.ekker)

Well, yes, it is improved. Looks like all options settings are reachable by keyboard again...

Flags: needinfo?(o.e.ekker)

Thanks for verifying!

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.