-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document Picture in Picture API #670
Comments
Is this different than the previous one in #72 |
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. |
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. |
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? |
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 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) 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:
We want to expose events that extensions could watch for to allow blocking.
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. |
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 |
For completeness's sake, the specification is available on WICG: https://github.com/WICG/document-picture-in-picture |
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 |
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 |
As a small addition, we also propose explicitly allowing Window's See the PR here: WICG/document-picture-in-picture#109 |
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 |
Another addition we're proposing is a new boolean parameter Initial request: WICG/document-picture-in-picture#113 |
We're considering a new boolean parameter Initial request: WICG/document-picture-in-picture#120 |
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. |
For info, Spotify folks are using the Document Picture-in-Picture API for their Miniplayer. |
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 |
As per discussion, would hiding the origin in so-called omnibox would be ever considered by modern browser's implementers ? Also could we, mundane developers expect, if not in Firefox , at least then in Chrome to see one day the support for window control overlay as found in PWA case ? It would be nice to see PWA like features exposed to PiP instantiated window as currently we're restricted only to user-agent native defaults, e.g. Chrome by default gives you "black" title bar and this is not bound to Chrome's default theme setting exposed to end-user... |
There are definitely some issues in the spec proposal, or Chrome's implementation not matching the spec, like apparently PiP affects fullscreen API, but it isn't defined how. Certain things are undefined, like when resizeTo/By() can be called. "only with a user gesture on the PiP window" is too vague. And disallowReturnToOpener is something up to the UA, mostly useful for the users, so that should be removed. I think conceptually this is quite reasonable. It is not that different from window.open("about:blank", "", "popup"); @steimelchrome are there plans to match the spec and Chrome's implementation? |
Hmm, mobile story is something to figure out. Looks like Chrome doesn't support the API on Android. But perhaps rejecting requestWindow() like the spec says wouldn't be too bad. (Mobile Chrome just doesn't seem to have the API exposed at all). There would be some risk for sites which are tested on desktop only to not work on mobile. |
Yes ideally the spec and Chrome's implementation would match. That's a good point that the spec doesn't mention fullscreen, I'll open an issue for that. In regards to resizeTo/By(), I believe https://wicg.github.io/document-picture-in-picture/#resizing-the-pip-window defines it reasonably well, but if you think there's something we should say differently in that section, I'm definitely open to improvements |
Oh, I see, it was the a bit unusual language in the proposal, "user gesture" meaning basically transient activation. |
Request for Mozilla Position on an Emerging Web Specification
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
The text was updated successfully, but these errors were encountered: