New issue
Advanced search Search tips

Issue 892469 link

Starred by 2 users
Status: WontFix
Owner: ----
Closed: Oct 5
Cc:
guidou@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

Cannot switch between back and front facing cameras on Acer Chromebook Tab 10

Reported by em...@seesaw.me, Oct 5 
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36

Steps to reproduce the problem:
1. On Acer Chomebook Tab, allow camera access. See that the front-facing camera turns on.  
2. Tap on the camera icon in the browser bar to switch to use the back facing camera. See that you cannot select from the list of cameras to edit the camera selection. Dropdown selector is disabled. 
3. If you tap Manage button, you can select the back facing camera from the dropdown in the Security settings menu. When you go back into the browser, you must refresh the page for the new permissions to take effect and then can use the back-facing camera. 

On other Chromebooks, you can switch between back and front facing cameras without needing to edit permissions in the Device settings. Once camera permission is allowed, you can just switch cameras. 

We are developing at https://app.seesaw.me. You can create a free teacher account, then tap the big green + button > Post to Student Journal > Take Photo to test our implementation. Test credentials can also be provided. 

What is the expected behavior?
User can switch between back and front facing cameras as long as camera permissions are allowed (without having to go into Device Settings to switch camera and then refresh page). 

What went wrong?
User cannot switch between back and front facing cameras without going into device settings, selecting other camera, and refreshing the web browser on Acer Chromebook Tablet. 

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 69.0.3497.100  Channel: stable
OS Version: OS X 10.12.6
Flash Version: 

Device: https://www.cdw.com/product/acer-chromebook-tab-10/5029412
API: https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices 
Our product: https://app.seesaw.me
Screenshot_2018-10-04_at_5_15_33_PM.png
1.5 MB View Download
Screenshot_2018-10-04_at_5_15_48_PM__1_.png
178 KB View Download
Screenshot_2018-10-04_at_5_17_48_PM.png
1.8 MB View Download

Comment 1 by swarnasree.mukkala@chromium.org, Oct 5

Labels: Needs-Triage-M69

Comment 2 by guidou@chromium.org, Oct 5

Status: WontFix (was: Unconfirmed)
Thanks for the report, but it seems that all this is working as intended and there is just a little confusion due to some UI issues.

First off, the selector in the omnibar (screenshots 1 and 3) is disabled because it does not (and is not intended to) allow switching camera on existing getUserMedia() capture sessions. The camera listed there is just informative.

For the second screenshot (chrome://settings/content/camera), the selector there just allows you to change what the default camera is going to be for future getUserMedia() calls (the application can override this by passing constraints to getUserMedia).  
Note that permissions in Chrome are not for specific devices, but for classes of devices. That is, permission to use the camera is a single permission for all cameras in the system, and, similarly, the microphone permission is a single permission for all microphones. Thus, there is no need to refresh for the permissions to take effect. 

It is not possible (as per the spec https://w3c.github.io/mediacapture-main/) to switch the camera for an existing MediaStream (no browser allows that). The application can, of course, close an existing stream, open a different camera and then show the new stream. It can even open both cameras at the same time if the system allows it. But this is an application issue. You can try https://webrtc.github.io/samples/src/content/devices/input-output/ for a demo that allows you to select among the different cameras in the system.

It is true that the UI might be confusing or misleading. We have bug 625769 (and probably some others) to track improvements to the permissions UI.  

Closing as WontFix since this seems to be working as intended.
►

Sign in to add a comment