Focus gets stuck in print preview when tabbing
Categories
(Toolkit :: Printing, defect, P2)
Tracking
()
People
(Reporter: Jamie, Assigned: Jamie)
References
Details
(Keywords: access, Whiteboard: [print2020_v81])
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-beta+
|
Details |
STR (on Windows; keystrokes/focus behaviour might be different on other OS):
- Open this URL:
data:text/html,<a href="https://mozilla.org/">Mozilla</a>
- Press shift+tab to focus the print preview.
- Repeatedly press tab and shift+tab to move focus out of the print preview.
- Expected: Tab should move focus out of the print preview. A few presses of shift+tab should, too.
- Actual: It doesn't; focus is stuck!
- Press control+l to focus the address bar.
- Press tab three times to focus the print preview.
- Repeatedly press tab and shift+tab to move focus out of the print preview.
- Expected: Tab should move focus out of the print preview. A few presses of shift+tab should, too.
- Actual: It doesn't; focus is stuck!
This is particularly bad combined with bug 1660359, since a screen reader user won't even know where focus landed and got stuck.
There are a few open questions here:
- Why does focus get stuck? Note that this doesn't happen if there are no focusable elements in the document. However, as soon as there is one focusable element, this happens.
- Is it useful to be able to focus the print preview at all? I'm guessing keyboard only sighted users might want to do this to scroll the preview, assuming this works?
- Should we even be able to tab or shift+tab into the print preview? My initial feeling was that tab/shift+tab should be restricted to the print settings and the browser chrome. If one did want to focus the print preview, one could do that with f6. However, this might be considered strange because the print preview is part of the print modal. Also, f6 is less discoverable if (2) is a common use case.
If we did want to disallow tabbing into the print preview (whether permanently or as an interim fix for getting stuck), maybe setting tabindex="-1" on its browser element would work, though I'm not sure. This does seem to work on iframes.
Assignee | ||
Updated•4 years ago
|
Comment 1•4 years ago
|
||
This should be fixed by bug 1657459 (which will prevent us from tabbing into it.
Updated•4 years ago
|
Assignee | ||
Comment 2•4 years ago
|
||
(In reply to James Teh [:Jamie] from comment #0)
If we did want to disallow tabbing into the print preview (whether permanently or as an interim fix for getting stuck), maybe setting tabindex="-1" on its browser element would work
It does, but it also prevents f6 from focusing the print preview.
Assignee | ||
Comment 3•4 years ago
|
||
Previously, IsFocusable returned true on elements in print preview documents, but the element wouldn't accept focus.
This meant that when you tried to tab, focus would get stuck on the document.
Now, IsFocusable returns false.
Thus, tab doesn't try to stop on these elements and can move out of the document.
Assignee | ||
Comment 4•4 years ago
|
||
The patch in comment 3 fixes this, but I suspect this probably isn't the right place to put this code.
Updated•4 years ago
|
Updated•4 years ago
|
Comment 7•4 years ago
|
||
Backed out changeset 44d25518ea20 (Bug 1660363) for causing bc failures in browser_modal_print.js
Backout link: https://hg.mozilla.org/integration/autoland/rev/a48af1a966b77975d525f615520b7e1e164ac1c1
Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=314052241&repo=autoland&lineNumber=22953
Assignee | ||
Comment 8•4 years ago
|
||
The failure was intermittent and was due to bug 1327274. If you shift+tab to print preview before the preview is initialised (i.e. while it is just a blank document), you won't be able to shift+tab any further. I haven't been able to reproduce this in manual testing, so I think it'll be pretty rare in the real world. For now, I worked around it in the test by waiting for the preview to be ready before shift+tabbing to it.
Comment 10•4 years ago
|
||
Backed out for bc failures on browser_modal_print.js
Backout link: https://hg.mozilla.org/integration/autoland/rev/fe9669e6a15ea049a2e0945d4ee9062352a6d612
Log link: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=314149130&repo=autoland&lineNumber=19042
Comment 11•4 years ago
|
||
Comment 12•4 years ago
|
||
bugherder |
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 14•4 years ago
|
||
Comment on attachment 9171635 [details]
Bug 1660363: Don't treat elements inside print preview documents as focusable.
Beta/Release Uplift Approval Request
- User impact if declined: Keyboard users (including screen reader users) will get "trapped" if they tab into print preview in the new print modal.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Change only affects print preview focusability. Covered by tests.
- String changes made/needed: None.
Comment 15•4 years ago
|
||
Comment on attachment 9171635 [details]
Bug 1660363: Don't treat elements inside print preview documents as focusable.
Approved for 81.0b5.
Comment 16•4 years ago
|
||
bugherder uplift |
Updated•4 years ago
|
Updated•4 years ago
|
Comment 17•4 years ago
|
||
Confirming this issue as verified fixed using Windows 10x64, macOS 10.15 and Ubuntu 18.04. Verified with 81.0b8 and 82.0a1 (2020-09-09).
Updated•1 year ago
|
Description
•