1659467 - Keyboard navigation not possible because new modal is not focused upon launch

Status: RESOLVED FIXED

(Toolkit :: Printing, defect)

Description

[Vlad Lucaci, Thunderbird QA (:vlucaci)]

Attachment: no keyboard navigation .gif

Affected versions

• 81.0a1(20200817093723)

Affected platforms

• Ubuntu 18.04
• macOS 10.15.6
• Windows 10x64
• Windows 10aarch64

Steps to reproduce

1. Launch FF.
2. Trigger the new Print UI modal.
3. Press tab to navigate options with keyboard.

Expected result

• New printing modal is focused as soon as it is opened and the user can navigate all the modal's options.

Actual result

• New UI modal is not focused and the Tab keyboard navigated the options of the page in the background.

Suggested Severity

• Seeing as how most of the users navigate the modal via mouse, and the fact that that the modal can still be interacted with keyboard(using Shift+Tab instead or selecting an option via mouse first) I see this issue as an S3.

Regression range

• Not a regression

Additional notes

• Screen cast of the issue:

Comment 1

[James Teh [:Jamie]]

This is intermittent for me; it sometimes gets focus and other times doesn't. However, this is pretty serious for screen reader users and potentially users of other accessibility tools. Screen reader users won't even know the print modal has appeared and won't know how to get to it.

Comment 2

[Blake Winton (:bwinton) (:☕️)]

(This should be fixed by the third patch on bug 1653317 so removing the [print2020_v81] whiteboard tag for easier tracking.)

Comment 3

[:Gijs (he/him)]

Jamie, can you see on a more recent nightly if this is fixed now bug 1653317 is fixed?

Comment 4

[James Teh [:Jamie]]

As I noted in comment 1, this was always intermittent for me, so I can't be certain. That said, I've tried in quite a few different scenarios and repeated attempts and I can no longer reproduce this.

Comment 5

[Maria Berlinger [:mberlinger], Services QA]

https://testrail.stage.mozaws.net/index.php?/cases/view/1084725