1718945 - Arrow keys are inverted when used on Permission panels

Status: RESOLVED WORKSFORME

(Firefox :: Site Identity, defect, P3)

Description

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Attachment: select_00.gif

Affected versions

• 91.0a1 (20210701211644)
• 90.0b12 (20210624190035)
• 89.0.2 (20210622155641)
• 78.11.0esr (20210531140902)

Affected platforms

• Windows 10x64

Steps to reproduce

1. Open Firefox and https://www.onlinemictest.com/webcam-test/.
2. Select to start the test.
3. Use the tab key to navigate to Allow/block buttons.
4. Use the Right/Left arrow keys.

Expected result

• If the Block button is focused-> Clicking Left arrow key should select Allow button.
• If the Allow button is focused-> Clicking Right arrow key should Select the Block button.

Actual result

• If the Block button is focused-> Clicking Left arrow key selects Remember this decision option.
• If the Allow button is focused-> Clicking Right arrow key selects Remember this decision option.

Regression range

• Last good revision: 3c68d659c2b715f811708f043a1e7169d77be2ba (2017-04-06)
  First bad revision: 10ea10d9993c9701e5525928257a589dea2c05d8 (2017-04-07)
  Pushlog:
  https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3c68d659c2b715f811708f043a1e7169d77be2ba&tochange=10ea10d9993c9701e5525928257a589dea2c05d8

Notes

• Attached a screen recording with the issue.
• Ubuntu 21.0.4 is working as expected and macOS 11 does not work (I will log another issue for this)

Comment 1

[Alice0775 White]

I can reproduce on Windows10.
Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=5806128b981e017cd27872ec17ccd1246e2603ce&tochange=001fd3755ac1810318bb7118b96ebbcc2a3e4a83

Comment 2

[:Gijs (he/him)]

The usual fix would be to set explicit tabindex attributes on these nodes, but doing that inside something as huge as browser.xhtml seems like a recipe for problems. So the only other thing I can think of here is replacing the css that reorders the buttons and causes the mismatch with JS that actually reorders the items.

That said, I am surprised by this nugget of info. In particular, in the argument to reach the current spec, fantasai argued:

Otherwise, you might as well reorder the content itself.

In practice, that's not what I've found. CSS order allows reordering that is much easier than DOM manipulation, especially when it comes to e.g. keeping the titlebar buttons at the far end of the toolbar (irrespective of allowing users to reorder siblings using customize mode). The other reason not to want to use DOM manipulation is that it breaks state, causes re-layout when the elements are reordered, etc.

I haven't checked but I expect all of these: https://searchfox.org/mozilla-central/search?q=%5Cbord%28er%7Cinal-group%29%3A&path=browser**css&case=false&regexp=true should affect the tab order.

Daniel, is there no better way to have the order/ordinal-group stuff affect the tab order/a11y tree?

Comment 3

[Daniel Holbert [:dholbert]]

The CSS that you linked uses CSS order, and he spec says the CSS order property does not affect tabbing-order:
https://drafts.csswg.org/css-flexbox-1/#order-accessibility

(In reply to :Gijs (he/him) from comment #2)
other reason not to want to use DOM manipulation is that it breaks state, causes re-layout when the elements are reordered, etc.

I think fantasai's comment was mostly regarding static content, not dynamic reordering. If you have a basic static page which includes flex items A and B, and you want B to be presented first visually and first from the perspective of tabbing-order, then you might as well just set up your DOM such that B is actually first. If on the other hand you want to have B appear first visually but second in tabbing-order, then order is what you want, to get the visual-only reordering.

I haven't checked but I expect all of these: https://searchfox.org/mozilla-central/search?q=%5Cbord%28er%7Cinal-group%29%3A&path=browser**css&case=false&regexp=true should affect the tab order.

I don't know about -moz-box-ordinal-group; but the order ones should not affect the tabbing-order, per spec.

And indeed, here's a reduced testcase that demonstrates this (correct) behavior of order not affecting tabbing order:
data:text/html,<div style="display:flex"><button style="order:2">first-in-dom</button><button>second-in-dom</button>

Comment 4

[Daniel Holbert [:dholbert]]

So, the short answer: no, there's no way to make the order property to affect the a11y/tab ordering tree.

AFAICT, the only ways to impact that are to reorder the DOM (i.e. to have it in the "correct" tab-index order in the first place with no dynamic changes so there's no relayout or loss of state, which as you note would be undesirable), or to use tabindex.

Comment 5

[:Gijs (he/him)]

(In reply to Daniel Holbert [:dholbert] from comment #3)

I haven't checked but I expect all of these: https://searchfox.org/mozilla-central/search?q=%5Cbord%28er%7Cinal-group%29%3A&path=browser**css&case=false&regexp=true should affect the tab order.

I don't know about -moz-box-ordinal-group; but the order ones should not affect the tabbing-order, per spec.

Sorry, I wasn't clear. I meant that, the front-end people who wrote the code expected the visual ordering to match the tab ordering, and for it not to matter how that visual ordering was achieved.

It sounds like there is no way to do that, without DOM manipulation, which is unfortunate.

Comment 6

[Tim Giles [:tgiles]]

:atrif, this appears to be fixed now as I can't reproduce the issue. Are you still able to reproduce the bug?

Comment 7

[:Gijs (he/him)]

(In reply to Tim Giles [:tgiles] from comment #6)

:atrif, this appears to be fixed now as I can't reproduce the issue. Are you still able to reproduce the bug?

We stopped using order in bug 1832348 so this got fixed in 120. (found by going forward in history from the link in comment #2). There do not appear to be many uses of order left so I think there's nothing left to do here.