1699284 - Some accesskeys in about:preferences cannot be cycled through

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, defect, P2)

Description

[Robin Steuber (she/her) [:bytesized]]

STR:

1. Determine the correct hotkey to use an accesskey on your platform using the docs. On my platform, Windows 10, the hotkey is Alt + Shift + <accesskey>.
2. Open about:preferences
3. Activate accesskey e multiple times. Observe that it cycles between the controls "Enable Picture in Picture video controls" and "Settings".
4. Activate the accesskey a multiple times.

Expected results:
There are multiple controls that use the accesskey a: The "Advanced" button in the "Font and Colors" section, and the "Always ask you where to save files" control in the "Files and Applications" section. Therefore, I would expect to cycle through them, like we do with accesskey e.

Actual results:
We do not cycle through them. We select the "Advanced" button only. As near as I can tell, other controls using the same accesskey cannot be accessed this way.

Comment 1

[Edgar Chen [:edgar]]

Attachment: Bug 1699284 - Part 2: Delegate focus handling to Element if accesskey won't cause activation; r=masayuki

PerformAccesskey also handle to focus change, and it would forward the handling
to control element if it is a label element.

Comment 2

[Edgar Chen [:edgar]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=b992d877d2954d8c311755076beeee12e69364aa

Comment 3

[Edgar Chen [:edgar]]

I will try to write a test.

Comment 4

[Edgar Chen [:edgar]]

Attachment: Bug 1699284 - Part 1: Update comment for PerformAccesskey; r=masayuki

I moved nsIContent::PerformAccesskey to Element in bug 1699755, but forget to
update the comment.

Depends on D109067

Comment 5

[Edgar Chen [:edgar]]

Attachment: Bug 1699284 - Part 3: Simplify nsXULElement::PerformAccesskey; r=masayuki

Depends on D109067

Comment 6

[Edgar Chen [:edgar]]

Attachment: Bug 1699284 - Part 4: Continue to search/try next accesskey target if current target is not focusable; r=masayuki

For example, if the target element is disabled, we could not move focus to it,
then we cycle to next accesskey target.

Depends on D109607

Comment 7

[Edgar Chen [:edgar]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=a86bb1615ef5b85202dbe3b0798d7a4a8a116419

Comment 8

[Edgar Chen [:edgar]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=06f4487b080750d1b0ec4b2594e4cbb897ae96dc

Comment 9

[Edgar Chen [:edgar]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=49fa707759b88cc880893e09705c3bc94212b778

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/08fd15f08503
Part 1: Update comment for PerformAccesskey; r=masayuki
https://hg.mozilla.org/integration/autoland/rev/29afdc442220
Part 2: Delegate focus handling to Element if accesskey won't cause activation; r=masayuki
https://hg.mozilla.org/integration/autoland/rev/d3ac5e547efe
Part 3: Simplify nsXULElement::PerformAccesskey; r=masayuki
https://hg.mozilla.org/integration/autoland/rev/62e36df25a9c
Part 4: Continue to search/try next accesskey target if current target is not focusable; r=masayuki

Comment 11

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/08fd15f08503
https://hg.mozilla.org/mozilla-central/rev/29afdc442220
https://hg.mozilla.org/mozilla-central/rev/d3ac5e547efe
https://hg.mozilla.org/mozilla-central/rev/62e36df25a9c