Closed Bug 1667125 Opened 4 years ago Closed 4 years ago

When VIDEO element has attribute "controls", event "pointerdown" cannot be captured on document

Categories

(Core :: Audio/Video, defect)

80 Branch
defect

Tracking

()

RESOLVED INVALID

People

(Reporter: contact, Unassigned)

References

Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:80.0) Gecko/20100101 Firefox/80.0

Steps to reproduce:

I've made a short sample on JSFIDDLE:
https://jsfiddle.net/Tolokoban/uv29sf7b/8/

I created two video elements. One with the "controls" attribute and the other without this attribute.

Then, I add event listeners on document, like this:

document.addEventListener("pointerdown", () => {
	document.body.classList.add("down")
}, true)
document.addEventListener("pointerup", () => {
	document.body.classList.remove("down")
}, true)

Actual results:

I use "capture" mode for my events on document.
But my pointerdown event is swallowed by the video with "controls" activated.

Expected results:

Since the event is captured on document, it should be got by my event handler even for video with controls.

This works fine on Google Chrome.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → DOM: Events
Product: Firefox → Core

It conditionally works on Chrome: pointerup does not fire when the cursor is on actual video controls. It never fires over audio controls.

I guess it's safe to close this as invalid and recommend setPointerCapture: https://jsfiddle.net/tvf41cm8/

Anne, do you see any objection?

Flags: needinfo?(annevk)

(In reply to Kagami :saschanaz from comment #2)

It conditionally works on Chrome: pointerup does not fire when the cursor is on actual video controls. It never fires over audio controls.

I guess it's safe to close this as invalid and recommend setPointerCapture: https://jsfiddle.net/tvf41cm8/

Anne, do you see any objection?

Maybe I was not clear, but I don't need the event to fire when the cursor is on the controls.
I just need this to work when the cursor is on the video.
I wanted to be able to drag videos around. So I should be able to touch the video and drag it anywhere else, but this is only possible if I get the pointerdown event.

When you use a <video src="..." controls>, clicking anywhere on the video (but not on the controls) toggle the pause/play action.

But nothing happens when you click on a <video src="...">.

I suppose that in a <video src="..." controls> the click just swallows my pointerdown event.
This is not expected since I capture the pointerdown event on the document itself.

So yeah, in Firefox the video itself becomes a control too. However, if that's not the case in other browsers it might lead to subtle compatibility issues so we probably need to reconsider that approach. And perhaps clarify the HTML Standard around this.

Flags: needinfo?(annevk)

This seems like a combination of Video/Audio Controls + HTMLMediaElement (Bug 1327097 seems to have put in place the code referenced in comment 3). Jared, do you know someone who would be well suited to look at this?

Flags: needinfo?(jaws)

alwu, could you take a look at this?

Flags: needinfo?(jaws) → needinfo?(alwu)

According to the spec [1], If the user agent exposes a user interface to the user by displaying controls over the media element, then the user agent should suppress any user interaction events while the user agent is interacting with this interface..

It seems to me that not dispatching pointer events in that situation is correct. In addition, according to [2], the reason Chrome would dispatch events is because the video part doesn't be regarded as a part of video control, which is different from Firefox's video control.

If we want to solve this compability issue, probably we should modify our video control in order to restrict its area only on the area B [2]. Any thought about that?

[1] https://html.spec.whatwg.org/#user-interface
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1327097#c89

Flags: needinfo?(alwu) → needinfo?(jaws)

Thanks, I haven't heard anything about us wanting to remove the overlay Play button so I think this bug is effectively "Invalid".

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Flags: needinfo?(jaws)
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.