w3c / presentation-api

Presentation API
https://www.w3.org/TR/presentation-api/
Other
71 stars 39 forks source link

One prompt for both PresentationRequest and RemotePlayback #470

Open takumif opened 5 years ago

takumif commented 5 years ago

Problem: Presentation API and Remote Playback API each has a method to start a session, namely PresentationRequest.start() and RemotePlayback.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:

const presentation = new PresentationRequest('https://example.com/myvideo.html');
const remote = document.querySelector('#my-video').remote;
const device = await navigator.secondScreen.prompt(presentation, remote);
// console.assert(device.supportsPresentation || device.supportsRemotePlayback);

if ((device.supportsPresentation && myPagePrefersPresentation()) ||
    !device.supportsRemotePlayback) {
  const connection = await device.startPresentation();  // Doesn't prompt
} else {
  device.startRemotePlayback();  // Doesn't prompt
}

Web IDL:

partial interface Navigator {
  readonly attribute SecondScreen secondScreen;
};

interface SecondScreen {
  Promise<SecondScreenDevice> prompt(PresentationRequest presentationRequest,
                                     RemotePlayback remotePlayback);
};

interface SecondScreenDevice {
  readonly attribute boolean supportsPresentation;
  readonly attribute boolean supportsRemotePlayback;

  Promise<PresentationConnection> startPresentation();
  Promise<void> startRemotePlayback();
};

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 and supportsRemotePlayback become false.

A call to startPresentation() or startRemotePlayback() gets rejected if supportsPresentation or supportsRemotePlayback is false, respectively.

pthatcherg commented 5 years ago

This looks good to me, but we should be aware that there are two limitations:

  1. 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.

  2. 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.

  3. 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?

markafoltz commented 5 years ago

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.

markafoltz commented 5 years ago

Possible background material: W3C Workshop on Permissions and User Consent