1667458 - PiP window closes when video element moved in DOM (eg youtube theater mode or miniplayer)

Status: REOPENED

(Toolkit :: Picture-in-Picture, defect, P3)

Description

[Almas Hossain[:mAlmas]]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0

Steps to reproduce:

User Agent :Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0

Steps to reproduce:

1. Open Firefox browser
2. Go to "www.youtube.com"
3. Play any video which duration more than 45 sec.
4. Click to "Picture-in-Picture" button on the right side of the video
5. Resize the youtube player screen (Not PiP) like, in Miniplayer/Theater mode while playing the video in Picture-in-Picture mode

Actual results:

Video playing screen in Picture-in-Picture mode is closed and it starts playing on youtube player.

Expected results:

It should continue the video in "Picture-in-Picture mode" if the youtube player screen is resized.

Comment 1

[:Gijs (he/him)]

I think this is by design - we assume that the user moving/resizing the video on the site is an indication they want to see it in there again. Mike, is that right?

Comment 2

[Mike Conley (:mconley) (:⚙️)]

I wouldn't say this is by design, no - what's happening is that by switching in another view (like the YouTube miniplayer by clicking the miniplayer button in the YouTube video controls), the original <video> element is being removed from the DOM, which is closing the Picture-in-Picture player window.

I don't think there's really a great way around this. We don't know, for example, what the site is going to do when they remove a <video> element, so we do the safe thing and just close the player window. I think that's the right call.

Comment 3

[Kestrel]

Chromium keeps the PiP window open when toggling youtube theater mode, miniplayer, fullscreen, navigating between videos and after removing the <video> element.

Reopening for Chrome parity consideration.

Comment 4

[Mike Conley (:mconley) (:⚙️)]

It does seem as if Chromium can handle if the <video> is removed from the DOM. I'm not entirely certain how this works, but it does seem as if the decoding of the video is not dependent on the video being bound to the DOM when it is PiP'd out.

Hey apehrson, do you happen to know how this works, and if this is something that our media layer could potentially support (allowing the playback of a <video> element to continue after DOM removal if we happen to be PiP'ing it?)

Comment 5

[Andreas Pehrson [:pehrsons]]

Technically this would be very simple to support. Here's a fiddle to test behavior: https://jsfiddle.net/pehrsons/vfr51uy6/

The spec situation is interesting because the spec says:

When a media element is removed from a Document, the user agent must run the following steps:

1. Await a stable state, allowing the task that removed the media element from the Document to continue. The synchronous section consists of all the remaining steps of this algorithm. (Steps in the synchronous section are marked with ⌛.)
2. ⌛ If the media element is in a document, return.
3. ⌛ Run the internal pause steps for the media element.

I'm not sure if the pip window should count as a document. This is out of the hands of the application so there would be some unexpected observable behavior, at least.

Comment 6

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

The severity field is not set for this bug.
:mhowell, could you have a look please?

For more information, please visit BugBot documentation.