Video player seek and volume controls no longer respond to mousewheel/scroll input when focused
Categories
(Toolkit :: Video/Audio Controls, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | unaffected |
firefox86 | --- | unaffected |
firefox87 | --- | wontfix |
firefox88 | --- | wontfix |
firefox89 | --- | wontfix |
firefox90 | --- | wontfix |
firefox91 | --- | fix-optional |
People
(Reporter: ke5trel, Unassigned, NeedInfo)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression)
STR:
- Visit https://www.w3schools.com/html/html5_video.asp.
- Click the seek bar or volume bar in the native video player to focus them.
- Hover the cursor over the controls and scroll the mousewheel or trackpad.
Expected:
Seek/volume bars move in response to scroll inputs.
Actual:
No response.
Workaround is to change media.videocontrols.keyboard-tab-to-all-controls = false
.
Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=8b552a1f8294b98f51274adf3b8bf3e9debf7c2f&tochange=a1ed33d27c4dd86b58ff8aca50adab96531fb12b
Regressed by Bug 1681007.
Comment 1•3 years ago
|
||
It seems to me that we have three conflicting requirements here:
- When keyboard users focus the seek or volume bar, they expect that all cursor keys will adjust that bar.
- As per bug 1350191, users want to be able to click the seek bar but not have the up/down arrow keys adjust the seek bar (like they normally would when focused on a slider). This conflicts with 1), so this was solved in bug 494175 by preventing mouse focus on the seek/volume bar.
- This bug, which expects that after clicking the seek/volume bar, mouse scrolling adjusts that bar. That requires focus, but that conflicts with the solution for 2), since mouse focus is now prevented.
Aside from the technical conflict between 2) and 3), it seems an inconsistent UX for mouse focus to alter scrolling behaviour but not keyboard behaviour.
In terms of implementation, I guess we can set a flag when a slider is focused via the mouse (as opposed to the keyboard). If that flag is set, the arrow keys ignore the focused control. This would allow us to manage all three requirements, though I'd argue the UX is still problematically inconsistent.
Kestrel, I notice you blocked bug 492516, which suggests you think this is an accessibility issue. Can you comment as to why you think it impacts accessibility? I'm just trying to determine whether this is a decision the accessibility team should drive or whether this is largely a UX/front-end decision.
Updated•3 years ago
|
Comment 2•3 years ago
|
||
Kestrel, needinfo ping?
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Description
•