New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 67 users

Issue metadata

Status: Duplicate
Merged: issue chromium:326740
Closed: May 2018
NextAction: ----
OS: ----
Pri: 2
Type: Bug

issue chromium:118551
issue chromium:326740

Sign in to add a comment

Issue 1757: Enable screen capture support in getUserMedia by default.

Reported by, May 10 2013

Issue description

What steps will reproduce the problem?
1. Download latest Chrome
2. goto chrome://flags
3. This flags is disabled by default " Enable screen capture support in getUserMedia()."

What is the expected result?
Would like to know when will this be enabled by default.

What do you see instead?
Would like to see the flag enabled by default.

Comment 1 by, May 10 2013

Project Member
This is unlikely to happen until at least M30 due to security concerns.

Comment 2 by, May 13 2013

Project Member
So should we close this issue for now or leave it until M30?

Comment 3 by, May 16 2013

Project Member
Leave it open for now, no mstone.

Comment 4 by, May 17 2013

Can this be allowed through a chrome extension? There are plugins downloaded for screen sharing.

Comment 5 by, May 18 2013

Project Member
Yes, apps and extensions will probably get access to this API before the drive-by web.

tabCapture is already exposed to extensions.

Comment 6 by, Oct 7 2013

Any update on this?

Comment 7 by, Oct 9 2013

Supported now via chrome extensions, but not exposed to the drive-by web.

Comment 8 by, Oct 9 2013

Is there a way to check programmatically (in JS) that this is not available. AFAIK GUM error will not allow to differentiate between this case and several other potential reason it would fail (even thought latest specs improve the granularity).

I'm ok with this function being behind a flag, as long as I can detect that it is not available before trying to use it, and/or i'm able to see it's not working because it's not available.

Comment 9 by, Oct 23 2013

Project Member
 Issue 2088  has been merged into this issue.

Comment 10 by, Oct 30 2013

Project Member
Labels: Mstone-33
Status: Assigned
Current plan is to open up chrome.desktopCapture.chooseDesktopMedia to all apps in M33. For M32, it will available in the Chrome dev and beta channels.

Comment 11 by, Oct 30 2013

Is that Apps and Extensions, or just Apps ?

Comment 12 by, Oct 30 2013

Project Member

Comment 13 by, Oct 30 2013

Google's Chromecast extension seem to make use of this API, I suppose it's white-listed since it works in M31?

Comment 14 by, Oct 30 2013

Project Member
Chromecast uses a different API to pick a tab; this API allows you to pick a desktop or particular window.

Comment 15 by, Oct 30 2013

Google's cast extensions currently uses getUserMedia to capture the desktop. You need to click the little down arrow and switch to the "Cast entire screen (experimental)" option.
I guessed that Google's extension was whitelisted for that API since from what I understand it doesn't work for other extensions.

Comment 16 by, Oct 30 2013

Project Member
Right, but what I am saying is that Chromecast doesn't use chrome.desktopCapture.chooseDesktopMedia, which is what is currently being discussed.

Comment 17 by, Nov 22 2013

BTW: it would be nice if it was also possible to select the area to be shared rather than just the full screen or a window

Comment 18 Deleted

Comment 19 by, Nov 22 2013

Project Member
Please create a separate enhancement request for region selection.

Comment 20 by, Dec 7 2013

Blocking: chromium:326740

Comment 21 by, Jan 15 2014

Project Member
Labels: -Mstone-33

Comment 22 by, Jan 15 2014

Project Member
Labels: Area-GetUserMedia

Comment 23 by, Jan 16 2014

Can you confirm if the roadmap calls for drive-by web to receive screen capture from getUserMedia, and for some variant of chooseDesktopMedia to be exposed as an API for drive-by web?

Comment 24 by, Jan 17 2014

Screen capture will not be available to the drive-by web in v1. chooseDesktopMedia will be available if an extension is present.

Comment 25 by, Jan 20 2014

But is there a plan to allow screensharing support for drive-by-web sometime this year? Or, waiting on the standardization process to agree on a security model?

Comment 26 by, Jan 21 2014

Right now there aren't any detailed proposals on the table for exposing screensharing to the drive-by web. So I think it's unlikely it will be part of WebRTC 1.0. 

This topic continues to get a lot of attention and I hope that we can find a solution for future versions of WebRTC.

Comment 27 by, Mar 17 2014

could we have an update regarding when these APIs will hit stable? 33 is out now and i noticed its still not available.

Comment 28 by, Mar 17 2014

chrome.desktopCapture.chooseDesktopMedia is available to beta in M33, and will be in M34 stable.

Comment 29 by, Apr 4 2014

Is M34 stable still the plan for choosedesktopmedia?  seems to have moved to M36.

Comment 30 by, May 7 2014

It looks as if a Chrome app that does contentscript injection has to be tied to a certain set of websites, and inline installation has to also be tied to a particular set of sites.

I have been looking at using screensharing in local installations - either customers taking an SDK and building their own WebRTC interfaces or installing pre-packaged solutions within a site. Proof-of-concept worked beautifully with the flag. But if the app has to be tied to a particular domain this simply won't work any more, since we won't know what site the SDK is being used on. This would potentially mean that every single site would need an app in the app store, right?

Furthermore, some customer sites may not even have external web access. This appears to be blocking a significant set of possible users, especially given proof-of-concept works with the flag but (unless I'm missing something) will not with the requirement to go via an app.

Comment 31 by, May 8 2014

Project Member
For deployment at sites without external web access, you can push an extension to users via Chrome corp policies.

Comment 32 by, May 8 2014

Thanks Justin, but that was a side issue. What about sites built on a SDK? That's my biggest concern here - we don't know where users will deploy the sites, so can't publish extensions to cover all possibilities. And we can't expect users to build and upload extensions for every site they deploy?

Comment 33 by, May 8 2014

Project Member
Can you give some specific examples?  We can discuss with our security team how you can best achieve your goals. Agree having 100 extensions that differ only by URL isn't ideal.

Comment 34 by, May 23 2014

We're doing something similar to Alan: our web conferencing software is distributed to companies who run it on their websites or their internal networks. It doesn't really make sense to have to publish our entire app as an extension just so we can get screen sharing on chrome, and if the extension is tied to one domain that makes even less sense.

Ideally we would like a cross-platform screen sharing API that doesn't require extensions or the user having to fiddle with flags.

Regarding security: if you're worried about users giving permission to a webpage to share their screen and then forgetting about it (or not realising that it's grabbing their entire desktop), why not have a small 'preview' window showing exactly what is being shared?

Comment 35 by, May 23 2014

Project Member
The concern isn't users forgetting. It's users being tricked into consenting, and then the attacking page grabbing everything they might want - email, bank info, anything you might happen to be logged into at the time.

We know from other clickjacking situations that users can be tricked in this way.

Comment 36 by, May 23 2014

In that case I would suggest having a slightly more dire warning to the user. Rather than simply having a little box they click that says something like 'enable screen sharing' (I can't remember the exact wording), have a larger warning box explaining the risks.

Right now screen sharing is the only missing feature in html5 for web conferencing.

Comment 37 by, May 23 2014

Project Member
Sadly, users often don't read dialog boxes. The browser still has to try to keep them safe from attackers nonetheless.

We don't have anything more to say on this now other than what I said in #24, but this issue is an ongoing discussion both internally and in standards organizations.

Comment 38 by, May 23 2014

> It doesn't really make sense to have to publish our entire app as an extension

You don't have to do this, the extension can be a small helper application (~50 lines of code) that calls chooseDesktopMedia and then returns the window id to the page js. tries to explain the whole process.

Sites will still have to upload their own extension in the store which is a less than ideal situation from the operational perspective. But the user experience has improved.

Comment 39 by, May 23 2014

Philipp - that URL 404s

Comment 40 by, May 23 2014

Thanks phillipp, that URL worked for me.

I'm pretty surprised that the extension just needs to grab an ID and pass it back to the host page.  This means that the MediaStream object still lives on the host page. Reading into the posted security risks section, the host page is still what controls the content on screen, so this doesn't seem to resolve all the concerns that come from the Same Origin Policy (read: But it does make the implementation of a screensharing service much easier :)

It does feel a little bit arbitrary to allow drive by web applications to use the screen as long as they upload this package to Google's store and the user is cool with downloading it (requires user to sign in and share data with Google). These applications end up with just as much control and with just as much of a loophole for malicious use. The user sees one extra prompt which isn't very transparent about the risks at all (the prompt to install an extension shows a description written by the application author, an icon uploaded by the author, and a public 'star' rating).

I think we should aim to do better. Better by the developers who want to use this functionality, and better by the users who want to use it while also knowing the browser has taken care of certain risks for them.

Comment 41 by, May 23 2014

>Sites will still have to upload their own extension in the store which is a less than ideal situation from the operational perspective. But the user experience has improved.

But the problem here for me, and the comment in #34, is that we do not know _where_ users will deploy the site so we cannot publish an extension specifically for it.

Prior to locking down extensions to only the Chrome Store (or enterprise policy), we could have auto-generated .crx files so the functionality was locked to the site once we knew where it had been installed. But this is no longer possible, so the only way I can see of achieving what we need is a global-match extension, which seems to be going against the purpose of making this an extension in the first place.

Comment 42 by, May 24 2014

I'd like an approach not unlike CORS to be considered as a solution. But that's up to the standard to specify.

Comment 43 by, Oct 17 2014

Jiayang is looking into what can be done about the origin policy.

Comment 44 by, Mar 17 2015

Is it possible to get ID for the tab and stream the tab instead of window/screen?

Comment 45 by, Mar 17 2015

Comment 46 by, Apr 20 2015

Project Member
Labels: EngTriaged

Comment 47 by, Nov 11 2015

Project Member

Comment 48 by, Jul 8 2016

Project Member
juberti@ any updates on this?

Comment 49 by, Oct 2 2016

I'd also like to know where this issue stands. Seems like a frequent request.

Comment 50 by, Feb 22 2017

Blocking: chromium:118551

Comment 51 by, Apr 11 2017

For what it's worth, Firefox just removed the screensharing whitelist which was requiring shipping custom extensions too:

Comment 52 Deleted

Comment 53 by, May 17 2018

Project Member
Mergedinto: chromium:326740
Status: Duplicate (was: Assigned)

Sign in to add a comment