Add option or method to set Picture-in-PictureWindow to maximum size programmatically

[guest271314]

Located this issue from

• Exposing/persisting width/height/top/left #2
• Interaction with <video> element styles #81
• Add note about styles #83
• 6daf2f2
• Add ability to set initial size of pip #122.

The title of the linked Chrome issue https://bugs.chromium.org/p/chromium/issues/detail?id=949570 does not contain the language of this feature request. To avoid confusion, filing this issue for clarity.

Note, it is not immediately obvious that the PictureInPicture window can be resized by user action.

It is apparently also not specified or possible by means of a workaround that have yet succeeded to resize PictureInPicture window programmatically. Persisting a user-resized Picture-in-Picture window requires running the code twice to begin recording at the maximum width or await pictureInPicture.width === screen.width/2 within resize event, then proceed, which is not necessarily possible for each attempt due to the implementation of the resized window, where the output should be met at the first attempt, without awaiting executing requestPictureInPicture() twice or width and height values at resize event initiated by user action.

(Though beyond the scope of this specific issue it should also be possible to resize Picture-in-Picture to fullscreen)

The use case for setting width and height of Picture-in-Picture programmatically, without user action, is recording PictureInPicture window, to utilize the unique playback capabilities of the Picture-in-Picture window.

[guest271314]

Example of the use case https://github.com/guest271314/MediaFragmentRecorder/edit/getdisplaymedia-pictureinpicture/MediaFragmentRecorder.html where it is not currently possible to resize PictureInPictureWindow programmatically, for example, using resizeTo() to match videoWidth and videoHeight of HTML pictureInPictureElement for the expected output of using getDisplayMedia() as a workaround for MediaRecorder stopping per specification when HTML <video> element src is changed.

[beaufortfrancois]

You can resize Picture-in-Picture window by adjusting video width and height. Give it a try at https://beaufortfrancois.github.io/sandbox/media/picture-in-picture-canvas

[guest271314]

Does the capability exist to resize Picture-in-Picture widnow exceeding screen.width/2 to match the videoWidth and videoHeight of the source media? If not, why?

[guest271314]

Why does the PictureInPictureWindow not match the exact width and height set?

[guest271314]

At the linked document when input is 400x300 output is 478x359.

The expected result is when input video has pixel dimensions 1280x720 PictureInPictureWindow should be capable of rendering those exact dimensions. If the src of the <video> changes and the videoWidth and videoHeight are 768x576, it should be possible to set those properties directly programmatically.

[guest271314]

@beaufortfrancois Must have not updated the branch at the above link at #163 (comment). Updated now with Picture-in-Picture code.

[alectrocute]

This would be a very great feature to have. I'd love to not resort to canvas hacks to achieve such a simple functionality.

[beaufortfrancois]

It seems like a Chrome issue rather an a spec issue. Let's continue this conversation at https://bugs.chromium.org/p/chromium/issues/detail?id=937859

[guest271314]

@beaufortfrancois It is a specification issue because of this language

It is also RECOMMENDED that the Picture-in-Picture window has a maximum and minimum size. For example, it could be restricted to be between a quarter and a half of one dimension of the screen.

which can be removed from the specification given that multiple parties have now expressed the interpretation of that recommendation by Chromium implementers is limiting use cases perhaps not conceived of by the specification authors, or in any event will not cause any issue that might have been conceived by not recommending arbitrary limitations on picture in picture window..

[guest271314]

PR #186 for clarity.

[beaufortfrancois]

Will pursue at #186!

[guest271314]

@beaufortfrancois

This issue needs to be re-opened.

So far nobody has explained or provided any reason either in this Issue or the PR or in the Chromium bug https://bugs.chromium.org/p/chromium/issues/detail?id=937859#c18 why this language

It is also RECOMMENDED that the Picture-in-Picture window has a maximum and
minimum size. For example, it could be restricted to be between a quarter and
a half of one dimension of the screen.

is in the specification.

[SableS]

I'd also like to ask as to why there is a recommendation to implement a maximum size.

From the closed PR (#186)

This suggestion comes from the experience of platforms and browsers implementing Picture-in-Picture (either the Web API or another sort).

How can this possibly be used as justification, when the limit has always been in place? Furthermore the Firefox equivalent does not implement this limitation. The chromium bug (here) was also closed without any justification, besides mlamouri's comment:

I do not believe we should re-visit this decision on anecdata. We believe that the size limitations match the use cases. We could add metrics to check what is the usual window size. Maybe it ends up mostly at its maximum size which would be a good signal.

These use cases are never actually elaborated on. I also note that this same person closed both that bug report with WontFix and #186 (I would comment there instead of here if that hadn't been locked).

It seems to mostly boil down to a member of the Chromium team believing there should be a limit, and therefore the limit should exist.

PiP is essentially just an always on top video player. Would you expect a desktop video player to limit size when in always on top mode (mpv, vlc etc)? They can, as should be expected, be resized at will, and even full-screened. The only possible reasoning I can think of for this limit is to stop a web page requesting an overly large size. This is sensible, and I would agree with a recommendation that suggests limiting initial size, but limiting resizing for the user is unwarranted.