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.