1327238 - Ctrl+Click doesn't work in timeline in video controls and volume bar, unlike for other buttons

Status: RESOLVED WONTFIX

(Toolkit :: Video/Audio Controls, defect)

Description

[arni2033]

>>>   My Info:   Win7_64, Nightly 53, 32bit, ID 20161119030204 (2016-11-19)
STR_1:
1. Open https://www.iandevlin.com/html5test/webvtt/html5-video-webvtt-sample.html , play the video
2. Hold Ctrl key
3. Click in the center of timeline

AR:  Video controls visually respond to click (blue circle becomes darker), but nothing else happens
ER:  Video should start playing from the middle, because I clicked there

Reference of good behavior:  other buttons in video controls work normally when I Ctrl+Click, w/o bug.

This is regression from bug 1271765. Regression range:
> https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ec7fb4f14d3ec23ded7eea40ff49ebbcbec6bde1&tochange=8d2eecb7ea5a16e02862dd326ce4519082ce9901

Comment 1

[Ray Lin[:ralin]]

It seems regressed by input[type="range"]. Is it necessary to support this behavior? (or is this desirable to video control). I'm sorry for I could not find an use case about it.

Comment 2

[Ray Lin[:ralin]]

Hi :stone

I found that other browsers are doing good at 'Ctrl+Click', but <input> in Firefox seems to refrain from triggering `change|input`. I tried to Is that a default behavior for input[type="range"] to ignore 'Ctrl+Click'?

I got a test page on codepen (please also open the 'console' panel on the codepen):
http://codepen.io/anon/pen/apWQgd

Thanks :)

Comment 3

[Ming-Chou Shih [:stone]]

Looks like current implementation doesn't allow drag range input when ctrl is pressed. Tested on other browsers (Chrome, Edge) and they don't block it.

Comment 4

[Ray Lin[:ralin]]

(In reply to Ming-Chou Shih [:stone] from comment #3)
> Looks like current implementation doesn't allow drag range input when ctrl
> is pressed. Tested on other browsers (Chrome, Edge) and they don't block it.

Thank you :stone, the result is same as what I've got in the test page. IMO, it should be possible to fire click event into slider and just make it behave as other elements. I wonder is there any background or security concerns to prevent `click+ctrl` on <input>? This bug is similar to Bug 1327097, which might take long time to confirm the desirable behavior, therefore, I think it's hard to tell the ETA now.

Comment 5

[Ming-Chou Shih [:stone]]

(In reply to Ray Lin[:ralin] from comment #4)
> (In reply to Ming-Chou Shih [:stone] from comment #3)
> Thank you :stone, the result is same as what I've got in the test page. IMO,
> it should be possible to fire click event into slider and just make it
> behave as other elements. I wonder is there any background or security
> concerns to prevent `click+ctrl` on <input>? This bug is similar to Bug
> 1327097, which might take long time to confirm the desirable behavior,
> therefore, I think it's hard to tell the ETA now.
I think it's a little bit different from bug 1327097. Spec says preventDefault could stop the default behavior and doesn't say there is an exception of shadow DOM.

About this bug, the UI events spec doesn't say key modifiers could change the default behavior of mouse down/up/click.

Comment 6

[Ming-Chou Shih [:stone]]

Attachment: Keyboard modifiers shouldn't block mouse events to trigger input behaviors

Comment 7

[Ming-Chou Shih [:stone]]

Comment on attachment 8832812 [details] [diff] [review]
Keyboard modifiers shouldn't block mouse events to trigger input behaviors

hi jwatt,

I'm wondering is it ok if we don't check keyboard modifiers when handling mouse or touch events in (range or number) input element? I tested on other browsers (Chrome, Safari, and Edge) and looks like they don't block the behaviors of mouse events with keyboard modifiers. Maybe there are some cases I should take into consideration. Could you give me some feedbacks? Thanks.

Comment 8

[Jonathan Watt [:jwatt]]

Comment on attachment 8832812 [details] [diff] [review]
Keyboard modifiers shouldn't block mouse events to trigger input behaviors

Hi! I feel we should continue to ignore clicks with modifier keys. If the user wants to change the value of the control why would they be pressing a modifier key when they get that behavior without going to the trouble of pressing it? It seems clear they're trying to do something else. In general ctrl+click brings up the context menu (on mac at least), so presumably that's what they're trying to do and what we should do. (We certainly shouldn't do two things and bring up the context menu AND change the value of the control.) So I'd personally close this as WONTFIX/INVALID. Thoughts?

Comment 9

[Ming-Chou Shih [:stone]]

(In reply to Jonathan Watt [:jwatt] from comment #8)
> Comment on attachment 8832812 [details] [diff] [review]
> Keyboard modifiers shouldn't block mouse events to trigger input behaviors
> 
> Hi! I feel we should continue to ignore clicks with modifier keys. If the
> user wants to change the value of the control why would they be pressing a
> modifier key when they get that behavior without going to the trouble of
> pressing it? It seems clear they're trying to do something else. In general
> ctrl+click brings up the context menu (on mac at least), so presumably
> that's what they're trying to do and what we should do. (We certainly
> shouldn't do two things and bring up the context menu AND change the value
> of the control.) So I'd personally close this as WONTFIX/INVALID. Thoughts?

It makes sense to me that we shouldn't do two things for one user action. Close it as won't fix since we don't see the necessary to change current behaviors. Feel free to re-open it if anyone has different thoughts.