Open takumif opened 5 years ago
This looks good to me, but we should be aware that there are two limitations:
You can't pass in multiple PresentationRequests or RemotePlaybacks (unless we added an argument to startPresentation/startRemotePlayback and generalized prompt to a list of objects). But this is probably fine for PresentationRequest and RemotePlayback since they have a list of URLs.
We can't easily add new types of things to prompt for in the future, unless we generalize prompt () and maybe make a general supports(x) and start(x). This will only matter if we think this will one day support more types of devices.
This doesn't support knowing whether or not the device supports both audio and video. Maybe it would be easy to extend that with a .supportsAudio and .supportsVideo on the SecondScreenDevice?
From TPAC F2F: https://www.w3.org/2019/09/16-webscreens-minutes.html#x04
RESOLVED: Create a pull request for a common prompt along the lines presented and gather feedback on the design from other groups
WebXR and WebRTC came up as possible groups for feedback.
An area of discussion is the scope of the permission. Is it based on time, duration of event loop, or something else?
Also need to follow up w/group leads about the right incubation path for new API features prior to rechartering.
Possible background material: W3C Workshop on Permissions and User Consent
Problem: Presentation API and Remote Playback API each has a method to start a session, namely
PresentationRequest.start()
andRemotePlayback.prompt()
. Each shows a potentially different list of receiver devices to choose from, so the user may need to open two different device selection dialogs to find a device.Proposed solution: We show a single dialog showing devices capable of either presentation or remote playback. After the user chooses a device, the controlling page initiates a presentation or remote playback depending on its preference and the chosen device's capabilities.
Example code:
Web IDL:
SecondScreenDevice
must expire after some time, to prevent the controller page from holding onto it and starting a session later when the user is not expecting.SecondScreenDevice
should become invalid at the same time as user gesture would become inactivated (UA dependent; in about one second on Chrome). Once invalid,supportsPresentation
andsupportsRemotePlayback
become false.A call to
startPresentation()
orstartRemotePlayback()
gets rejected ifsupportsPresentation
orsupportsRemotePlayback
is false, respectively.