Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

getDisplayMedia with Chrome 72 throwing Not Allowed #16513

Open
iclems opened this issue Jan 23, 2019 · 18 comments · Fixed by #16763
Open

getDisplayMedia with Chrome 72 throwing Not Allowed #16513

iclems opened this issue Jan 23, 2019 · 18 comments · Fixed by #16763

Comments

@iclems
Copy link

@iclems iclems commented Jan 23, 2019

  • Output of node_modules/.bin/electron --version: v5.0.0-nightly.20190107
  • Operating System (Platform and Version): macOS Mojave 10.14.2 (18C54)
  • Output of node_modules/.bin/electron --version on last known working Electron version (if applicable): never

Expected Behavior
Using navigator.mediaDevices.getDisplayMedia({ video: true }), a native screen picker should appear.

Actual behavior
The following error is thrown: NotAllowedError: Permission denied

Screenshots
Expected dialog
image

@codebytere

This comment has been minimized.

Copy link
Member

@codebytere codebytere commented Jan 23, 2019

@iclems this is probably related to: #16508

@sofianguy sofianguy added this to Unsorted Issues in 5.0.x Jan 25, 2019
@ckerr ckerr moved this from Unsorted Issues to Doesn't Block Stable in 5.0.x Jan 31, 2019
@MarshallOfSound

This comment has been minimized.

Copy link
Member

@MarshallOfSound MarshallOfSound commented Jan 31, 2019

Using navigator.mediaDevices.getDisplayMedia({ video: true }), a native screen picker should appear.

This behavior isn't expected for Electron's case. If we were to implement the plumbing required for this to work we would implement it similar to select-bluetooth-device where we emit all possible options and then the app is responsible for the "choosing" part, whether that is through a UI or just choosing a specific device by default 🤷‍♂️

@iclems

This comment has been minimized.

Copy link
Author

@iclems iclems commented Jan 31, 2019

Interesting. I understand the previous perspective on this feature but it is now part of the WebRTC standards and no longer a Chrome-specific capability implemented through extensions. It sounds strange to have an official W3C "stable" API that needs to be rebuilt via private SDKs. Certainly makes sense in the short-term, but I would assume the long-term path should be: the official API works, but developers can build a custom UI instead if they like?

@sofianguy sofianguy moved this from Doesn't Block Stable to Fixed for Next Release in 5.0.x Feb 7, 2019
@iclems

This comment has been minimized.

Copy link
Author

@iclems iclems commented Feb 15, 2019

FYI even with 5.0.0-beta.3 which includes the fix this is still not working throwing NotAllowedError: Permission denied.

@codebytere

This comment has been minimized.

Copy link
Member

@codebytere codebytere commented Feb 15, 2019

@brenca ☝️

@sofianguy sofianguy moved this from Fixed for Next Release to Blog Post Information in 5.0.x Feb 18, 2019
@sofianguy sofianguy moved this from Blog Post Information to Fixed in 5.0.0-beta.3 in 5.0.x Feb 18, 2019
@iclems

This comment has been minimized.

Copy link
Author

@iclems iclems commented Mar 7, 2019

@brenca @sofianguy @codebytere could you reopen and make sure this isn't marked as fixed in the release notes as I just tested again in beta 5 and it is still throwing NotAllowedError: Permission denied. I'm happy to help fix it but I'm not an expert in the native binding behind it

@MarshallOfSound

This comment has been minimized.

Copy link
Member

@MarshallOfSound MarshallOfSound commented Mar 7, 2019

Haven't confirmed but re-opening, @brenca can you double check this? Feel free to close again if the fix has indeed been applied successfully

@connetcom

This comment has been minimized.

Copy link

@connetcom connetcom commented Apr 16, 2019

Hi any update on this or is there an alternative place to track status? I am on Chrome 73.0.3683.90 on Android 8.0.0. and the same exception not allowed is thrown.

Thanks

@nornagon

This comment has been minimized.

Copy link
Member

@nornagon nornagon commented Apr 16, 2019

Hi @connetcom, Electron doesn't run on Android so we can't possibly be responsible for whatever issue you're running into. You might have better luck at https://crbug.com.

@connetcom

This comment has been minimized.

Copy link

@connetcom connetcom commented Apr 16, 2019

Thanks for the link and sorry i had somehow shifted into the wrong thread as i was looking at a bunch of stuff at the same time and did not realize that i was on electron.

@juniiorlima

This comment has been minimized.

Copy link

@juniiorlima juniiorlima commented May 5, 2019

  • Output of node_modules/.bin/electron --version: v5.0.0-nightly.20190107
  • Operating System (Platform and Version): macOS Mojave 10.14.2 (18C54)
  • Output of node_modules/.bin/electron --version on last known working Electron version (if applicable): never

Expected Behavior
Using navigator.mediaDevices.getDisplayMedia({ video: true }), a native screen picker should appear.

Actual behavior
The following error is thrown: NotAllowedError: Permission denied

Screenshots
Expected dialog
image

Solution:

https://electronjs.org/docs/api/desktop-capturer
https://qiita.com/gtk2k/items/ac08ddeeaf74f3126f81

@iclems

This comment has been minimized.

Copy link
Author

@iclems iclems commented May 6, 2019

I agree the above mentioned link states a correct workaround but it uses the long supported DesktopCapture. The topic here is about supporting a now standard WebRTC API.

@angelohub

This comment has been minimized.

Copy link

@angelohub angelohub commented Jun 13, 2019

Is there any update for this? Would be great to be able to use the new WebRTC API for screensharing.

@CapOM

This comment has been minimized.

Copy link
Contributor

@CapOM CapOM commented Aug 16, 2019

@iclems If getDisplayMedia was working in electron as expected, would the user still have the use the UI picker provided by chromium or is it possible to avoid that and still enumerate the sources ? So one can implement its own UI for the picker ?

@JerryFZhang

This comment has been minimized.

Copy link

@JerryFZhang JerryFZhang commented Oct 24, 2019

Any updates on this? Thanks!

@ffflorian

This comment has been minimized.

Copy link

@ffflorian ffflorian commented Oct 30, 2019

This is still the case for Electron 6.1.2 and 7.0.0.

@squalle0nhart

This comment has been minimized.

Copy link

@squalle0nhart squalle0nhart commented Nov 22, 2019

Any update ? It's good if electron support standard WebRTC API.

@saghul

This comment has been minimized.

Copy link
Contributor

@saghul saghul commented Nov 22, 2019

There is no chance this is supported on Electron unless either of these is met:

  1. Electron implements a picker UI (which they have refused to do so far)
  2. Electron creates a non-standard constraint for getDisplayMedia so the source ID can be passed

Chrome has no intention to deprecate using getUserMedia for desktop capture (all you can do now on Electron) in the near future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
5.0.x
Fixed in 5.0.0-beta.3
Linked pull requests

Successfully merging a pull request may close this issue.

You can’t perform that action at this time.