[Media Router] chrome.cast.desktopCapturePrivate API for desktop capture |
|||
Issue descriptionThis FR tracks the work for a new API to support desktop capture for Media Router (Cast). The API is private as it will support a subset of features of the existing desktopCapture API and be whitelisted to the Media Router. Proposal: chrome.cast.desktopCapturePrivate.chooseScreenMedia(callback) chrome.cast.desktopCapturePrivate.cancelChooseScreenMedia(requestId) Takes: |callback| Invoked with an opaque stream id for the screen to be captured, or null if the request was cancelled or had an error. Returns: An integer requestId used to cancel a pending request. Behavior: - If the user has a single screen media source, invokes |callback| immediately with the stream id. - If the user has multiple sources, shows the same picker as chooseDesktopMedia with screen sources and allows the user to choose one. - Audio capture is always requested and the audio checkbox is NOT shown in the picker. - The title and messaging in the picker may be further tweaked for Cast, however, we are not going to go crazy here and reuse the existing picker code as much as possible.
,
Oct 27 2016
Do we need a separate "private" API for this? IIRC, we already whitelist the MR extension in the public API implementation to avoid having it prompt with an extra user permissions dialog. We could simply make sure the UI workflow/behavior matches what we discussed when the MR extension is detected in the current API impl.
,
Oct 27 2016
The feedback from sergeyu@ was to create a separate API rather than overload the existing one with different behavior when called by a specific component. From an API design standpoint, I tend to agree that having very different behavior based on the identity of the caller is not the best.
,
Oct 28 2016
triage: setting status to assigned.
,
Oct 28 2016
untriaged w/ owner -> assigned for triage.
,
Mar 1 2018
We're revamping our entire UX and a new desktop casting flow will be part of that effort. Not worth investing effort here. |
|||
►
Sign in to add a comment |
|||
Comment 1 by mfo...@chromium.org
, Oct 27 2016