New issue
Advanced search Search tips

Issue 660191 link

Starred by 0 users

Issue metadata

Status: WontFix
Owner:
Closed: Mar 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 2
Type: Feature



Sign in to add a comment

[Media Router] chrome.cast.desktopCapturePrivate API for desktop capture

Project Member Reported by mfo...@chromium.org, Oct 27 2016

Issue description

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



 
 

Comment 1 by mfo...@chromium.org, Oct 27 2016

Summary: [Media Router] chrome.cast.desktopCapturePrivate API for desktop capture (was: [Media Router] Private API for desktop capture)

Comment 2 by m...@chromium.org, 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.

Comment 3 by mfo...@chromium.org, 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.


Status: Assigned (was: Untriaged)
triage: setting status to assigned.
untriaged w/ owner -> assigned for triage.
Status: WontFix (was: Assigned)
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