screensharing access is denied if you have previously denied access to camera/microphone
Reported by
a...@tokbox.com,
Jan 23 2017
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 Example URL: http://meet.tokbox.com/testingScreenshare Steps to reproduce the problem: 1. Go to https://meet.tokbox.com/testingScreenshare 2. Deny access to the camera/microphone 3. Click the share screen button 4. Select the screen you wish to share and click "Share" What is the expected behavior? Your screen starts being shared What went wrong? You get a permission denied error Did this work before? N/A Is it a problem with Flash or HTML5? HTML5 Does this work in other browsers? No Firefox Chrome version: 55.0.2883.95 Channel: stable OS Version: OS X 10.12.2 Flash Version: Shockwave Flash 24.0 r0 It seems strange that the user would be prompted to select the screen they wish to share and then be told that they denied permission. Contents of chrome://gpu: Graphics Feature Status Canvas: Hardware accelerated Flash: Hardware accelerated Flash Stage3D: Hardware accelerated Flash Stage3D Baseline profile: Hardware accelerated Compositing: Hardware accelerated Multiple Raster Threads: Enabled Native GpuMemoryBuffers: Hardware accelerated Rasterization: Hardware accelerated Video Decode: Hardware accelerated Video Encode: Hardware accelerated VPx Video Decode: Hardware accelerated WebGL: Hardware accelerated Driver Bug Workarounds disable_framebuffer_cmaa disable_multimonitor_multisampling get_frag_data_info_bug needs_offscreen_buffer_workaround pack_parameters_workaround_with_pack_buffer regenerate_struct_names scalarize_vec_and_mat_constructor_args set_zero_level_before_generating_mipmap unfold_short_circuit_as_ternary_operation unpack_alignment_workaround_with_unpack_buffer unpack_overlapping_rows_separately_unpack_buffer use_intermediary_for_copy_texture_image use_shadowed_tex_level_params
,
Jan 23 2017
Able to reproduce the issue on Mac 10.12.2,Win 10 & Ubuntu 14.04 using 55.0.2883.9/87 and canary 58.0.2999.0. This is a non-regression issue since 47.0.2526.106 and prior to it the application was not supported. Note: FireFox too behaves the same way.
,
Jan 23 2017
,
Jan 26 2017
,
Jan 31 2017
,
Jan 31 2017
Is screen capture tied to the camera permission because content::IsVideoMediaType()? If so, at the very least we should make sure it's not shown if camera is blocked. But generally, if the user has to go through the "choose *what* to share" dialog every time the capture is initiated, then I don't think this needs to be protected by a content setting at all, as we get an explicit consent each time. In fact, bundling this with "camera" might even be a bit misleading since it's literally not camera, even though it's a type of video stream.
,
Feb 21 2017
@guidou actually, we realised this was due to a bug in our SDK which wraps getUserMedia. We resolved it and this confirms Chrome is able to share the screen after denying camera access with no issues. Recommend closing this.
,
Feb 21 2017
Closing as per comment #7 |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by a...@tokbox.com
, Jan 23 2017