allow origin to open PiP window from inactive tab (with previous explicit consent by the user)

[egm0121]

Hello,

For some use cases related to Video conferencing (one of the cited use cases for this new feature) it would be great if the PictureInPicture could be triggered programmatically. eg. when receiving an incoming video call in a web-based videoconference solution. or showing call controls for an inbound call that is automatically accepted (call center agent)

Popups created programmatically with windows.open are blocked by default but a notification is shown to let the user allow popups if needed.

Could PiP behave in the same way? this would enable use cases that are not currently possible on web apps but are used in desktop applications.

[beaufortfrancois]

FYI @steimelchrome and @liberato-at-chromium are thinking of ways to enhance Picture-in-Picture user experience. See https://github.com/w3c/mediasession/issues/294 for instance.

[liberato-at-chromium]

This is an interesting case. If I understand correctly, and please correct me if I don't, the page might already be backgrounded at the time it decides that it wants to enter pip.

[egm0121]

Correct, the tab will get events of incoming call or connected call via websocket events while the user might be interacting with another app. Having the ability to show the PiP window from a non active tab allows for the active call controls to show up seamlessly for the user

[liberato-at-chromium]

One concern I have is that there is a fairly big potential for abuse: a non-foreground site being able to open a pip window would allow for some really bad behavior. Scoping the ability correctly is the tricky part.

[tomayac]

This seems especially desirable in the context of crbug/1446327, which is about the PiP window disappearing after the computer was locked.

[egm0121]

@liberato-at-chromium could there be a new permission in the navigator.permissions API to let the user explicitly authorize "background-pip" for a specific origin?

[liberato-at-chromium]

crbug/1446327: Possibly, though that one might just be a chrome bug that would also affect this new type of background-pip as well.

background-pip permission: Even with a permission, we might want additional strong hints about when a permission request will be auto-denied by the UA. We also might want to restrict when a site can initiate background-pip even after the permission is granted. "Always allow a site to open a pip window from the background" might be too strong.

It might even be undesirable for a site to know the user preference for background-pip, else it could bother the user into allowing it. I think there will be a very strong monetary incentive for sites to do that. A permission might not be appropriate because of it.

I freely admit that I'm not very good at the nuances of this sort of privacy / abuse analysis -- so my opinions expressed above are of dubious value :)

[egm0121]

@liberato-at-chromium I'm not an expert on whats the best way to safely allow background pip, but it does open up powerful uses cases that can make web apps closer in features with desktop apps.

One idea is that the permission could be auto denied by the UA if the website has not previously opened a PiP following user interaction in the foreground. This way a website would not be able to bother the user multiple times if the user has not voluntary triggered a PiP before.