Exposing/persisting width/height/top/left about picture-in-picture HOT 9 CLOSED

For users who regularly view using PIP, sticky position/size would be nice. Do we generally expect UAs to do this, or as with something like mute do we expect the site to persist this across API invocations? If the latter, how do sites read this information so that they can persist it?

The idea here is that the website can recommend a size and position to the UA which can follow or ignore this recommendation. It might also not be able to follow it because of system recommendations: the system APIs might not offer this option. I would be interested to see if system APIs allow the caller to move the PIP window after it was created. It sounds unlikely but if it's the case, we could consider exposing this. We would also need to report the current position to the website in order to allow the feature you suggested.

Do we expect to expose any control over whether users can resize PIP windows? (On desktop this seems particularly useful).

The UI should be left as an implementation details. The specification should recommend to have some controls but, for example, resizing might make sense in some contexts (desktop) but not on mobile. Also, implementations re-using system APIs will have not much controls over this.

If users can resize PIP windows, how do we expose this to the page? ABR logic that decides among multiple possible encodes with different resolutions often depends on this.

I think that's an interesting use case. I wonder if native APIs expose this.

How do we handle multiple displays? Especially if they have different properties (e.g. DPI) that affect content rendering?

I guess multiple displays should be handled like for any window.

In general, it sounds like you would be interested to have PIP handled closer to a Window instead of a display mode. Do I understand this correctly?

from picture-in-picture.

For users who regularly view using PIP, sticky position/size would be nice. Do we generally expect UAs to do this, or as with something like mute do we expect the site to persist this across API invocations? If the latter, how do sites read this information so that they can persist it?

I would prefer that pip window position/size suggested by websites would be ignored if user moved or resized it later on:

1. Website A video.requestPictureInPicture({top: 100, left: 100, width: 640, height: 480}); open a 640x480 pip window at 100,100.
2. User moves pip window at 200,200
3. Website A video.requestPictureInPicture({top: 100, left: 100, width: 640, height: 480}); open a 640x480 pip window at 200,200 (because user set it before).
4. Website B video.requestPictureInPicture({top: 100, left: 100, width: 640, height: 480}); open a 640x480 pip window at 100,100 (because it is the first time Website B asks for a pip video)

If that makes sense, I can add it to the spec.

If users can resize PIP windows, how do we expose this to the page? ABR logic that decides among multiple possible encodes with different resolutions often depends on this.

FYI, macOS doesn't seem to expose pip window size and changes.
Note that its pip window can't be larger than a quarter of the display though.

Shall we add an event to handle ABR case though?

video.addEventListener('resizepictureinpicture', function(event) {
  // User resized element in Picture-In-Picture mode.
  console.log('New video width:' + event.data.videoWidth);
  console.log('New video height:' + event.data.videoHeight);
});

from picture-in-picture.

It sounds to me that we could split this issue in two:

• position/size set by the website/user/system, it'l similar to #5
• ABR related requirements: window size, screen capabilities

from picture-in-picture.

Regarding the ABR case, instead of having a resizepictureinpicture how about something like this?

const pipWindow = await video.requestPictureInPicture();

console.log(pipWindow.width); // PiP window width
console.log(pipWindow.height); // PiP window height

pipWindow.addEventListener('resize', event => { 
  // User resized PiP window.
  console.log(event.target.width, event.target.height);
});

(edit: s/pipVideo/pipWindow)

from picture-in-picture.

I find this more elegant and flexible than the resizepictureinpicture event. What type of obejct would pipVideo be here? Could we imagine this being a PictureInPictureWindow or something like that with some properties/events that we would need/want to expose?

(edit: renaming interface stub name to avoid confusion)

from picture-in-picture.

@jernoble, what do you think of this way of handling PiP window resizing?

from picture-in-picture.

Does requestPictureInPicture() have the possibility of being rejected? If so, requestPictureInPicture() may want to return a Promise that resolves to a PiPWindow object (or PictureInPictureContext, if the Window nomenclature is too overloaded).

from picture-in-picture.

Thanks @jernoble. Sounds like we are completely aligned as your comment matches @beaufortfrancois's above. We will send a PR soon.

from picture-in-picture.

@jernoble Here it is: #31

from picture-in-picture.