Skip to content
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

One prompt for both PresentationRequest and RemotePlayback #470

Open
takumif opened this issue Sep 5, 2019 · 3 comments
Open

One prompt for both PresentationRequest and RemotePlayback #470

takumif opened this issue Sep 5, 2019 · 3 comments
Assignees
Labels

Comments

@takumif
Copy link

takumif commented Sep 5, 2019

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
Copy link

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?

@mfoltzgoogle
Copy link
Contributor

mfoltzgoogle commented Sep 18, 2019

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.

@mfoltzgoogle
Copy link
Contributor

Possible background material: W3C Workshop on Permissions and User Consent

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants