Document Picture in Picture API

[liberato-at-chromium]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Document Picture-in-Picture
• Explainer URL: https://github.com/steimelchrome/document-pip-explainer/blob/main/explainer.md
• Caniuse.com URL (optional):
• Bugzilla URL (optional):
• Mozillians who can provide input (optional):

Other information

The API that's in the explainer is approximate but well within the spirit of what we'd like to end up with. Any feedback is appreciated!

Link to chromestatus entry: https://chromestatus.com/feature/5755179560337408

[nschonni]

Is this different than the previous one in #72

[liberato-at-chromium]

Yes, it is different. #72 is for video content only. This newer proposal provides support for arbitrary web content in a picture in picture window.

[muratcorlu]

This reminds me of old-school popups. PiP for a specific type of content (for video only for now) is a safe approach for most users. But if websites get access for putting any content to a PiP window, I'm afraid we'll see very annoying advertisement windows everywhere. And people will start searching for "how to disable PiP". Eventually, this will kill PiP feature completely.

[bgrins]

I'd like to hear more about how UAs should expect to handle sites overusing / abusing this - particularly with a new windowing mode that may not be perceived as coming from the web page. Should popup blockers treat this identically to window.open? And would those controls affect video PiP as well?

[liberato-at-chromium]

This reminds me of old-school popups.

Thank you for voicing these concerns. I agree that popups would not be a good outcome. However, I don't believe that Document PiP makes the situation any worse.

Specifically, even with video-only PiP, sites can display arbitrary content; it's easy to make a one-frame video and/or redirect a video stream from a <canvas> to a PiP window for live, site-controlled content.

Further, the proposal for Document PiP is that it requires a user gesture, which is the same as video-only PiP or (usually, but I believe not required by spec) window.open(). For a site to open a Document PiP window, it would already be able to open either of the other types anyway. Plus, the lifetime of the PiP window is explicitly tied to that of the opener, unlike window.open(); when the opener closes / navigates away, any PiP window closes. This is the same as video-only PiP.

The value in this proposal, as I see it, is allowing sites to provide more value via input.

Since these questions are in the same spirit as the above, I'll answer them together:

Should popup blockers treat this identically to window.open? And would those controls affect video PiP as well?

We want to expose events that extensions could watch for to allow blocking.

particularly with a new windowing mode that may not be perceived as coming from the web page

Making sure that it's clearly web content is definitely a goal, though it'll be up to the UA exactly how to do that. For example, we plan to have Chromium display the origin of the opener in a slimmed-down title bar so that it's clear to the user what they're interacting with.

[foolip]

FYI, there's an Intent to Ship for this feature on blink-dev now: https://groups.google.com/a/chromium.org/g/blink-dev/c/JTPl7fM64Lc/m/t-qwrAKmAAAJ

[BasixKOR]

For completeness's sake, the specification is available on WICG: https://github.com/WICG/document-picture-in-picture

[bllngr]

And it's now available in Google Meet on Chrome browsers: https://workspaceupdates.googleblog.com/2023/06/enhanced-experience-picture-in-picture-google-meet-chrome.html

[steimelchrome]

For the initial launch of this API, Chrome disabled the ability for websites to use the resizeTo() and resizeBy() Window APIs to avoid spammy abuse given the always-on-top nature of a document picture-in-picture window. We've received feedback from multiple websites that having access to these APIs would be useful (e.g. clicking to expand a playlist). We propose a change to allow access to those APIs, but gated behind a user gesture (consumed) to limit potential abuse.

See the PR here: WICG/document-picture-in-picture#104

[steimelchrome]

As a small addition, we also propose explicitly allowing Window's focus() API to focus the opener window from the picturein-in-picture window, so that websites can programmatically return to the opener tab. This consumes a user gesture from the picture-in-picture window.

See the PR here: WICG/document-picture-in-picture#109

[beaufortfrancois]

As requested by developers, we proposed adding display-mode for picture-in-picture to CSS Media Queries Level 5.

@media all and (display-mode: picture-in-picture) {
  body {
    margin: 0;
  }
  h1 {
    font-size: 0.8em;
  }
}

See the PR here: w3c/csswg-drafts#9920

[steimelchrome]

Another addition we're proposing is a new boolean parameter disallowReturnToOpener, which defaults to false. When set to true, it hints to the user agent that showing a button in the document picture-in-picture UI that allows the user to return to the opener does not make sense for their use case, so the user agent can hide the button.

Initial request: WICG/document-picture-in-picture#113
PR: WICG/document-picture-in-picture#114, WICG/document-picture-in-picture#116

[liberato-at-chromium]

We're considering a new boolean parameter disallowPositionReuse to give the site control whether the UA should optionally try to remember the previous picture-in-picture window's position and size (false, the default), or place the new window according to its default positioning / sizing heuristics. The idea is that retaining the window's position and size can be confusing if the contents of the new pip window are semantically unrelated to the previous one (e.g., a new video, a new meeting, etc.).

Initial request: WICG/document-picture-in-picture#120
PR: WICG/document-picture-in-picture#119

[steimelchrome]

We're also proposing allowing user gestures in the document picture-in-picture window to be usable in the opener window and vice versa. This makes it more ergonomic to use user-activation-gated APIs, since often event handlers in the document picture-in-picture window are actually run in the opener's context, so the opener's context needs access to the user gesture. This essentially makes the document picture-in-picture window act the same as a same-origin iframe inside the opener as far as user gesture propagation is concerned.

PR: WICG/document-picture-in-picture#117

[beaufortfrancois]

For info, Spotify folks are using the Document Picture-in-Picture API for their Miniplayer.
You can learn more about their journey and use cases at https://developer.chrome.com/blog/spotify-picture-in-picture

[steimelchrome]

Adding a small change to copy the Document mode from the opener (e.g. quirks mode or non-quirks mode):

PR: WICG/document-picture-in-picture#128
Chromestatus: https://chromestatus.com/feature/6275022143094784