1845864 - inert embedded video still responds to play/pause key

Status: NEW

(Core :: DOM: UI Events & Focus Handling, enhancement)

Description

[ataylor32]

Attachment: Demo

Steps to reproduce:

(1) Open the attached HTML file
(2) Start playing the embedded YouTube video
(3) Click the "Inert" checkbox to make the embedded YouTube video's iframe inert
(4) Press the play/pause key on the keyboard

Actual results:

The video paused.

Expected results:

The video should continue playing due to the inert attribute being present on the iframe.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Graphics: WebRender' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Mayank Bansal]

I cant repro this bug (i.e. When I try the STR, the video continues to play).
In any case, this should not be a webrender issue. Tentatively reclassifying to DOM:UI events.

Comment 3

[Peter Van der Beken [:peterv]]

It's reproducible, but I don't think it's a valid bug. Inert is defined in the HTML spec: https://html.spec.whatwg.org/#inert, and I suppose you could argue that since the iframe can't be focused the keys shouldn't have any effect. However the keyboard multimedia keys are a user agent feature that works a bit independently, for example if there are two videos on the page both are stopped. As such I think they're not affected by inertness.

Comment 4

[ataylor32]

According to MDN, the inert attribute "makes the browser ignore input events sent by the user". That makes me think this is a valid bug.

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I agree with peterv, Gecko has a media controller outside the DOM, and it seems that it does not check disabled nor inert. Once browsers allow web apps to disable user interaction of media elements, users cannot stop/mute unexpected media play.

Gijs and karlt: I'm not sure who handles the UI design, are you or do you know?

Comment 6

[Karl Tomlinson (:karlt)]

Alastor would know more about the intended mediacontroller behavior.
I suspect "makes the browser ignore input events sent by the user" was not written considering system-level mediacontroller events, but intended to cover specific events as it goes on to list. MDN is not the definition of truth here anyway.

Comment 7

[ataylor32]

From the spec:

Content in an inert subtree will not be perceivable by all users, or interactive

Currently, users can interact with an inert video with the play/pause key on their keyboard.

Perhaps it will help if I explain my real world use case rather than using the attached demo. I have a <dialog> that I want to be able to be dismissed, but not remove the content of it because the user may reopen it. I have it set up so that when the <dialog> is dismissed, the video within it automatically pauses. But if the user presses the play/pause key on their keyboard, the video starts playing again even though the <dialog> isn't visible. I added the inert attribute to prevent this, but that didn't solve the problem.

Comment 8

[Alastor Wu [:alwu]]

This is an interesting issue. I'm not sure if we should exclude inert element for the media control. But more specifically, I would always want media control to be able to pause ANY playing media, but it seems ok to me that we can exclude inert element from the media control if that element has been paused.

However, from the point of the web compatibility, Chrome/Edge/Safari all have same behavior with Firefox, the element can still be controlled by media keys even if the element has been marked as inert. In addition, according to this, By default, there is no visual way to tell whether or not an element or its subtree is inert. So if we decide to support not to resume the inert element, there is no visual clue to tell users why it doesn't work.

Perhaps it will help if I explain my real world use case rather than using the attached demo. I have a <dialog> that I want to be able to be dismissed, but not remove the content of it because the user may reopen it. I have it set up so that when the <dialog> is dismissed, the video within it automatically pauses. But if the user presses the play/pause key on their keyboard, the video starts playing again even though the <dialog> isn't visible. I added the inert attribute to prevent this, but that didn't solve the problem.

If so, I would suggest you to use MediaSession: setActionHandler to set your own handler on play and pause to determine what video should be controlled.