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 18 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Jul 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment
link

Issue 459532: Bypass popup to grant desktop sharing by WebRTC

Reported by boni...@gmail.com, Feb 18 2015

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.111 Safari/537.36

Example URL:

Steps to reproduce the problem:
1. Share a desktop by WebRTC (https://talky.io/ can be used to reproduce the problem)
2. A popup asking for user grant to share desktop is shown

What is the expected behavior?
It would be very useful (for testing purposes) to bypass the grant popup.

What went wrong?
It is not possible to bypass the popup which appears when the desktop is shared by WebRTC. This behaviour makes impossible to perform automated tests of this kind of applications.

It would be very useful if a flag like --use-fake-ui-for-media-stream (to avoid popup granting access to the cam/micro) for desktop sharing. The closest existing flag now is --auto-select-desktop-capture-source, but this flag is only to automate the window picker.

Did this work before? N/A 

Is it a problem with Flash or HTML5? HTML5

Does this work in other browsers? N/A 

Chrome version: 40.0.2214.111  Channel: stable
OS Version: 
Flash Version: Shockwave Flash 16.0 r0
 

Comment 1 by dalecur...@chromium.org, Feb 18 2015

Labels: -Cr-Internals-Media Cr-Blink-WebRTC

Comment 2 by kjellander@chromium.org, Feb 19 2015

Owner: phoglund@chromium.org
Status: Assigned
[triage] phoglund will take a look at implementing something here.

Comment 3 by phoglund@chromium.org, Feb 20 2015

Labels: Needs-Feedback
I'm not sure what popup you're referring to here. Using the most recent Chrome, I tried out/Debug/chrome --use-fake-device-for-media-stream --use-fake-ui-for-media-stream --auto-select-desktop-capture-source="Entire screen" and went to talky.io. I clicked the let's go button, went into the room and clicked Share screen. 

It asked me to install an extension. I did so, and then clicked share screen again. Talky then launches the "you are about to join a video chat" window (this pop-up is blocked by the pop-up blocker though, so I have to allow it to do that). I click join in the popup. 

I click screenshare again, the window picker launches but is closed by the auto-select flag, as if I'd chosen to share my entire screen. The screen share fails with Uncaught TypeError: Cannot read property 'focus' of undefined (which seems to be a bug in talky?)

I expected you were getting caught on some kind of "talky wants to share your desktop" pop-up built into Chrome, but I can't see any such pop-up here. Which one are you referring to? Note that the talky popup is launched by Talky and you should be able to interact with that one using Webdriver or similar.

Comment 4 by boni...@gmail.com, Feb 21 2015

The site https://talky.io/ is not the best one to reproduce the issue. Sorry about that, my bad. I made others tests with online pages to be able to reproduce it.

These tests have been made on Ubuntu 14.04 64-bits, and I used Google Chrome stable (40), beta (41) and dev (42) as follows:

Version 40.0.2214.115 (64-bit)
------------------------------

1. Open Chrome:
google-chrome --enable-usermedia-screen-capturing

2. Browse URL
https://www.webrtc-experiment.com/Pluginfree-Screen-Sharing/

3. Click on "Share Your Screen"

4. The popup I would like to avoid appears here (see attached picture "popup.png")

If we repeat the process changing step 1, opening Chrome as follows:
google-chrome --enable-usermedia-screen-capturing --use-fake-ui-for-media-stream

... in this case desktop sharing is not supported. An error popup is shown (see atached picture "error.png"). It seems that flag --enable-usermedia-screen-capturing is not compatible with --use-fake-ui-for-media-stream


Version 41.0.2272.64 beta (64-bit)
----------------------------------

Step 1 now is:
google-chrome-beta --enable-usermedia-screen-capturing

... the behaviour is exactly the same (also appears "popup.png")

When adding --use-fake-ui-for-media-stream flag:
google-chrome-beta --enable-usermedia-screen-capturing --use-fake-ui-for-media-stream

... in this case desktop is not shared, instead the media from my cam is used.


Version 42.0.2305.3 dev (64-bit)
--------------------------------

Step 1 now is:
google-chrome-unstable --enable-usermedia-screen-capturing

... the behaviour is exactly the same (also appears "popup.png")

When adding --use-fake-ui-for-media-stream flag:
google-chrome-unstable --enable-usermedia-screen-capturing --use-fake-ui-for-media-stream

... the same behaviour that with beta version (desktop is not shared, instead the media from the cam).


Hope this helps. Thanks a lot for your support!
error.png
57.2 KB View Download
popup.png
56.4 KB View Download

Comment 5 by phoglund@chromium.org, Feb 25 2015

Right, so the difference is you're not using an extension, whereas Talky is. I wonder if this should simply fall under --use-fake-ui-for-media-stream.

Comment 6 by boni...@gmail.com, Feb 26 2015

Indeed, in the second example I am not using any extensions and the popup I would like to bypass appears.

On the other hand, in my experience it seems there is something wrong with --use-fake-ui-for-media-stream, since this flag in combination with --enable-usermedia-screen-capturing the screen sharing is not working anymore.

Comment 7 by phoglund@chromium.org, Feb 26 2015

Ok, unfortunately this is quite complex to implement, at least without hacking it. Why do you need this capability anyway, can't you just create a test extension and run your tests that way?

Comment 8 by boni...@gmail.com, Mar 1 2015

It is not important for me the combination of --use-fake-ui-for-media-stream with --enable-usermedia-screen-capturing.

What I would like to do is bypass (if possible) the popup asking for permission (attached picture "popup.png") when Chrome is executed using just --enable-usermedia-screen-capturing without extensions.

Comment 9 by phoglund@chromium.org, Mar 2 2015

Ok, let me try to clarify my question: Why do you need to test your service with --enable-usermedia-screen-capturing? Since I very much assume any real service will not require their users to restart Chrome with a flag, I assume there must be an extension. Why not, in that case, test with the extension instead?

Comment 10 by boni...@gmail.com, Mar 2 2015

I would need this feature just for testing purposes. I mean, for our production services, indeed we have created an extension similar to talky.io. But for tests the situation is a bit different.

For example, we use Selenium Grid and Saucelabs PAAS as clients in our tests. In these scenarios, the Chrome browsers are not managed by me. In other words, I cannot ensure these browsers has installed any extension. On the other hand, I am able to open such browsers with the --enable-usermedia-screen-capturing flag (when Selenium WebDriver is created). But the test cannot be executed since it required human intervention to grant the desktop sharing.

This is the concrete test scenario I would like to bypass with a hypothetical new flag.

Comment 11 by phoglund@chromium.org, Mar 2 2015

I see. Yeah, that kind of sucks. I'll take a new look tomorrow and see if I can figure it out.

Comment 12 by pthatcher@chromium.org, Mar 2 2015

Labels: WebrtcTriaged

Comment 13 by tnakamura@chromium.org, Mar 4 2015

Labels: -Needs-Feedback
-Needs-Feedback based on discussion up to #11. phoglund@, if you still have open questions, feel free to re-add that label.

Comment 14 by phoglund@chromium.org, Mar 9 2015

Sorry about the delays, kind of swamped with work.

Comment 15 by phoglund@chromium.org, Apr 17 2015

Owner: ----
Status: Available
I took another look at this today, and the problem is that this case doesn't fit well into the current design. The --use-fake-ui-for-media-stream today intercepts calls on a level above media_capture_devices_dispatcher.cc and plugs in fake media for video and audio. We could do the same thing for desktop (i.e. just generate some video and audio), but nothing like that is implemented today. We also can't reach for the "real" desktop video flow since that's on the level below of where we intercept the call. The right thing here would be to implement a fake desktop source, which I think would take on the order of a few days.

Unfortunately I can't spare that amount of time, so I'm setting this to Available for now. Maybe someone else will come along to fix this later. Sorry. Patches are welcome though!

Comment 16 Deleted

Comment 17 by boni...@gmail.com, Apr 28 2015

I finally found a workaround to bypass the window picker popup, event in a browser controlled by Selenium Grid or Saucelabs.

Luckily, Selenium WebDriver in Chrome can be started with a custom extension (in this case the one to share desktop). Even better, although this extension is located at the local file system, it is sent to remote browsers when using Selenium Grid (I noticed  the content of the extension is encoded in base64 and sent to the node).

Using this workaround, the flag --auto-select-desktop-capture-source indeed is useful to pick the window of the desktop sahring. Here it is the snippet of Selenium WedDriver (in Java) to implement this workaround:

ChromeOptions options = new ChromeOptions();
File crx = new File("/path/to/extension.crx");
options.addExtensions(crx);
options.addArguments("--auto-select-desktop-capture-source=Entire screen");
Driver driver = new ChromeDriver(options);

Thanks for the support!

Comment 18 by Deleted ...@, Apr 28 2015

Should this be working on mac now or is there a special build of chrome I need to get for it to work on mac?  

I have verified chrome is receiving the argument "--auto-select-desktop-capture-source=Entire screen" but it still shows me the window picker popup and does not make a selection.  Thanks for any help.  I believe I have tried the latest stable, beta, and dev builds of chrome.

Comment 19 by boni...@gmail.com, Apr 29 2015

I tried that on Chrome 42 in Linux, and also in Chrome 41 on Windows 8.1 through Saucelabs. In both cases my workaround works. I suppose it should be working also in Mac...

Comment 20 by philipp....@gmail.com, Nov 12 2015

phoglund: how difficult would it be to exempt desktop capture from the fake devices case? I.e. could
   chromeMediaSource: 'desktop'
still return the real desktop even if --use-fake-ui-for-media-stream, use-fake-device-for-media-stream and --auto-select-desktop-capture-source are set?

I'd like to have combined audio/video/screensharing tests but that seems not possible right now. Unless I'm wrong about this?

Comment 21 by phoglund@chromium.org, Nov 29 2015

Re #20: I still don't know how to fit it into the current design. Desktop capture is handled differently than gUM, which is what I've implemented support for. I don't remember exactly where I got stuck earlier, but I know it was harder than just bypassing the prompt.

You can try getting hold of someone that knows desktop capture better and try to get them to implement a bypass of the prompt. You can probably find hints in OWNERS files and blame information (for instance https://chromium.googlesource.com/chromium/src/+blame/master/chrome/browser/media/media_capture_devices_dispatcher.h).

Comment 22 by philipp....@googlemail.com, Mar 14 2016

#21: actually there is a effective workaround for the problem I described in #20:
Generate a preferences file with persistent cam/mic permissions (e.g. using seleniums setUserPreferences on the chrome options) and don't use --use-fake-ui-for-media-stream.

Comment 23 by jshen...@gmail.com, May 24 2016

Hey comment 22, I really like the idea of this workaround, but can you provide an example of how you set the cam/mic permissions?

Comment 24 by jshen...@gmail.com, May 24 2016

Nevermind I got it using this:
prefs: {
      "profile": {
        "content_settings": {
          "exceptions": {
            "media_stream_camera": {
              "https://*,*": {
              	"setting": 1
              }
            },
            "media_stream_mic": {
              "https://*,*": {
              	"setting": 1
              }
            }
          }
        }
      }
    },

Comment 25 by jansson@chromium.org, Jul 8 2016

Cc: phoglund@chromium.org
phoglund@ do you think the workaround in #24 is sufficient?

Comment 26 by phoglund@chromium.org, Jul 8 2016

Status: WontFix (was: Available)
Yes, and no savior has stepped up to fix this, so I think that'll have to do.

Comment 27 by douglasm...@gmail.com, Feb 24 2017

Sorry to raise this question again, but did anyone find any answer to this problem?

Comment 28 by philipp....@googlemail.com, Feb 24 2017

#27: comment 22+24 shows how to work around it.

Sign in to add a comment