status of chrome.desktopCapture.chooseDesktopMedia integration?

[Dennis]

I'm trying to figure out when 'chrome.desktopCapture.chooseDesktopMedia' will be available to use from a web page.  

from previous posts I think I saw that this is going to be the officially supported API for selecting a specific application window for sharing but as of today you still have to have the extension manually installed for this API to work.   therefore I am assuming the plan moving forward is to integrate this extension into native chrome at some point such that a user no longer has to manually install this extension, correct?

I thought I read a while ago this was supposed to be integrated in M34 but clearly that's not the case as I tested M34,35, and canary 36 and the API still won't work without having the extension manually installed.

I'm also trying to figure out the right issues to watch for updates on this manner. I think it's the following but not sure if there is another I might be missing:

https://code.google.com/p/webrtc/issues/detail?id=1757 
https://code.google.com/p/chromium/issues/detail?id=347641

So basically, my questions are:

1) is my understanding of the above correct in that 'chrome.desktopCapture.chooseDesktopMedia' will be the official API to use for selection specific application windows to share and that it is to be integrated natively with chrome at some point?

2) what is the plan for the integrated target release version?

3) are there any other issues other than the two above I should be watching for updates?

Thanks,Dennis

[Jiayang Liu]

AFAIK, chrome.desktopCapture.chooseDesktopMedia is designed as an extension API, and will not be accessible from drive-by web, for security reasons.

The two bugs are you referring to are about screen sharing using "chromeMediaSource:screen" in getUserMedia, which is under a flag and will be moved to beta/dev/canary channels only, which means stable channel users will not be able to enable the flag.

So the recommended way to do screen/window sharing is to use chrome.desktopCapture.chooseDesktopMedia and let your users install the extension, possibly from the Chrome Store.

[Dennis]

I think I misunderstood what ' 'chrome.desktopCapture.chooseDesktopMedia'  was.  I thought this was an extension itself, but you're saying that this is an API for use within an extension, of which one has to develop the extension itself and that there is no "official" google extension that uses 'chooseDesktopMedia' , right?  

[Dennis]

Also, I thought "chromeMediaSource:screen" in getUserMedia was going to be enabled for Stable in M35 or M36, is that not true?

On Monday, April 7, 2014 1:43:45 PM UTC-4, Jiayang Liu wrote:

[Benjamin Schwartz]

It sounds like you may not have listed the "desktopCapture" permission requirement in your extension's manifest.  Note that you can go to chrome://extensions and pull up a debug console in your extension's environment, which may make it easier to understand these kinds of issues.

On Tue, Apr 8, 2014 at 6:30 AM, Dennis <ddo...@gmail.com> wrote:

I also cannot even get this API to work from an extension.  When invoking I get the following error:

Uncaught TypeError: Cannot read property 'chooseDesktopMedia' of undefined 

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jiayang Liu]

This is an example extension demonstrating the API:

https://code.google.com/p/chromium/codesearch#chromium/src/chrome/common/extensions/docs/examples/api/desktopCapture/&q=desktopcapture&sq=package:chromium

--

---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/j6jmyBFt9QI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.

[Justin Uberti]

We are being cautious with this API due to the security implications, and chooseDesktopMedia provides a safer path.

There are no plans to expose chromeMediaSource:screen in stable at this time.

--

[consynchr...@gmail.com]

chrome.desktopCapture.chooseDesktopMedia how to know the source(screen or window) selected by user, i am getting id and stream id. 

[Leighton Carr]

Sorry for the necro here, I've run into this issue and I'm still a bit unclear about the plans for this in terms of access for the web, particularly as it relates to this issue:

https://code.google.com/p/webrtc/issues/detail?id=2787

Is the intent that we won't be able to cast a specific monitor for WebRTC without having to use an extension?  If so, that's a little suboptimal for the ideal of WebRTC, and it significantly limits web developers.

I hope I'm misunderstanding!

Cheers,

Leighton.

[Alexandre GOUAILLARD]

right now, screensharing is a chrome only feature, and is implemented as a privileged API (i.e. it requires you to develop an extension to access it).

At the last w3c/IETF meeting it was decided that screensharing be part of webRTC 1.0 specs, even if in a separate document, following a strong pushed from Mozilla. 

You should see more details emerging post IETF meeting (july 25) and before w3c's TPAC (october 27th).

alex.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Alex. Gouaillard, PhD, PhD, MBA

------------------------------------------------------------------------------------

CTO - Temasys Communications, S'pore / Mountain View

President - CoSMo Software, Cambridge, MA

------------------------------------------------------------------------------------

sg.linkedin.com/agouaillard

• 
  

[Hari Poludasu]

Hi Justin,

Are there any plans to extend current desktopshare API to give desktop control to remote parties involved in session?

Regards,

Hari

[Justin Uberti]

Not at this time; the security risks here are quite high, as you might imagine.

You could use native messaging to build a helper application do to the remote control though, and it would get its input over a data channel.

[Eric Burns]

Alex (et al) ... was there any movement on including screensharing as part of WebRTC 1.0 after these meetings?

(I would even settle for it being Chrome-only if it didn't require our users to install our extension)  :o)

Thanks!

[Philipp Hancke]

2014-11-15 5:16 GMT-08:00 Eric Burns <eric.mich...@gmail.com>:

Alex (et al) ... was there any movement on including screensharing as part of WebRTC 1.0 after these meetings?

(I would even settle for it being Chrome-only if it didn't require our users to install our extension)  :o)

FWIW, Mozilla's screensharing works just fine and you only need an extension if you want to avoid explaining your users how to manipulate the whitelist. 

[Alexandre GOUAILLARD]

well ...

- martin from mozilla is working on the specs for the group.

- It s gonna be a separate document from the webrtc 1.0 spec.

- the committee agreed to keep going, but this part of the spec were not mature enough to take any other decision at this point.

- the API itself (GUM) will not really change

It seems that the decision about how to deal with security will be left to the browser vendor, and will not be specified in the spec. Practically you can already see the difference: chrome has one model (extension) and firefox (starting f33) another one (white listing, pre-populated, mutable, ...), temasys plugin has another one, and so on and so forth. The chrome extension actually only create the capturer (using the extension allow to differentiate between different levels of access inside the code), and make the corresponding stream/track available to a subsequent, normal, call to GUM.

I voiced my concerns, saying that the variation between the normal (for cam) GUM prompts between browsers or versions of browsers was already a huge problem for web devs, and that making the variations bigger for screen sharing would lead to a lot of problems. I'm not sure I have been heard. As long as the API itself does not change, the security behavior is the prerogative of the browser, and not of w3c WG. Harald stopped the discussion at that point.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Eric Burns]

Thanks for the update, Alexandre!  (and Phillip)