Open Bug 1701481 Opened 10 months ago Updated 7 months ago

Video player seek and volume controls no longer respond to mousewheel/scroll input when focused

Categories

(Toolkit :: Video/Audio Controls, defect, P3)

Firefox 87
defect

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:

  1. Visit https://www.w3schools.com/html/html5_video.asp.
  2. Click the seek bar or volume bar in the native video player to focus them.
  3. 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.

It seems to me that we have three conflicting requirements here:

  1. When keyboard users focus the seek or volume bar, they expect that all cursor keys will adjust that bar.
  2. 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.
  3. 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.

Flags: needinfo?(ke5trel)

Kestrel, needinfo ping?

Severity: -- → S4
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.