New issue
Advanced search Search tips

Issue 708081 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Apr 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

It should be possible to change the input device from the browser UI when deviceId constraints are specified in getUserMedia call

Reported by iamcraig...@gmail.com, Apr 4 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36

Steps to reproduce the problem:
1. Go to https://webrtc.github.io/samples/src/content/devices/input-output/
2. Click allow to allow microphone access (make sure your volume is turned down/off so you dont end up with bad feedback) 
3. Click on the camera icon in the URL bar and notice how you can change the input devices (screenshot 1)
4. Change the audio input source to a specific source (such as Built-in Microphone on MacOS)
5. Click on the camera icon again and notice how the options to change the input devices are disabled

What is the expected behavior?
You should be allowed to change the input at the browser level regardless of the constraints (deviceId) passed to getUserMedia

What went wrong?
The option to change inputs is disabled

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 57.0.2987.133  Channel: stable
OS Version: OS X 10.12.4
Flash Version: 

This is more of a browser UX issue since the getUserMedia and MediaDevice APIs seem to be working correctly according to the spec. 

I personally think that regardless of what device the developer of an app says to use, the person viewing your site should be able to choose the input device they want to use. 

My use case is that I am working on an audio app where the audio input device can be selected in the UI of the app, but what I really would like is for it to be able to be selected in EITHER the Chrome UI or the app UI. That doesn’t seem possible right now because as soon as I pass in a constraint to getUserMedia for a specific deviceId (selected in my app UI) there is no way to change it from the Chrome UI. 

As of right now it is arguably a better user experience to not use deviceId constraints at all (at least for audio devices) and let the selection in the Chrome UI for the audio input device be used directly. In the Chrome UI, if you change the input device to “Built-In Microphone” and then refresh the page, it is sticky and remembers your selection while still offering the ability to change the input device to something else.

--

On a side note related to that, if the user changes the input device initially using the Chrome UI (camera icon), there is no way to know that from the web UI (that I am aware of). You can reproduce that pretty easily on the same demo page:

After allowing microphone access, change the microphone in the Chrome UI then refresh the page. You will see that the Chrome UI has “Built-In Microphone” selected while the page itself still shows “Default”.

Let me know if you would prefer this to be ticketed separately
 
before.png
61.3 KB View Download
after.png
61.2 KB View Download
Just to clarify, in step 4 above I meant to say change the audio input source to a specific source from the web interface (not from Chrome UI)
Labels: Needs-Triage-M57
Cc: guidou@chromium.org
guidou@, you agree?
The dialog from the url bar is highly misleading since it doesn't allow changing the device for the current getUserMedia call, but instead it just changes the default device stored in preferences (can also be changed via chrome://settings).
There are plans to change the UI, but so far it hasn't been implemented.

Up to Chrome 57, the device selector appears disabled if a device is specified with deviceId constraints, and enabled if no constraints are passed. This is highly irregular.
Chrome 58 implements a more spec-compliant constraints algorithm and it results in the selector being always disabled for cameras.

Personally, I think that the UI should be revamped, but, as long as the dialog exists, the selectors should be always disabled since all they do is change a user setting unrelated to the request that is currently executing. 
@guidou I just tested in Canary and see what you mean about the camera, but the microphone input still behaves the same way I mentioned in this ticket. 

That still doesn’t solve the second case I brought up where if you change the microphone in the Chrome UI (before choosing a device from navigator.MediaDevices) there is no way for your application to know that the browser default device has changed.

Showing them as disabled makes some sense to me since there is no way to sync them back to each other, but I think in an ideal world the Chrome input matches up with the current getUserMedia constraint.
And if that were the case then there would have to be some event fired when the Chrome input changes to let your application stay in sync (maybe the ondevicechange callback?)

Comment 7 by guidou@chromium.org, Apr 11 2017

Owner: guidou@chromium.org
Status: Assigned (was: Unconfirmed)
Project Member

Comment 8 by bugdroid1@chromium.org, Apr 11 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/82382cca8c9aa804acb7fd9cfaa6e4478f92cd7d

commit 82382cca8c9aa804acb7fd9cfaa6e4478f92cd7d
Author: guidou <guidou@chromium.org>
Date: Tue Apr 11 14:38:48 2017

Initialize default audio device ID with explicit device ID.

This is more consistent with how video device IDs are specified and is
also a small first step towards implementing the standard constraints
algorithm for audio.
This CL disables a misleading selector that allows switching the
user-preferred device in the middle of a getUserMedia call.
Since that selector does not affect the current getUserMedia call, it
is better to have it disabled, which is already the case with video
devices.

BUG= 708081 

Review-Url: https://codereview.chromium.org/2812903002
Cr-Commit-Position: refs/heads/master@{#463624}

[modify] https://crrev.com/82382cca8c9aa804acb7fd9cfaa6e4478f92cd7d/content/browser/renderer_host/media/media_stream_manager.cc
[modify] https://crrev.com/82382cca8c9aa804acb7fd9cfaa6e4478f92cd7d/content/browser/renderer_host/media/media_stream_manager.h
[modify] https://crrev.com/82382cca8c9aa804acb7fd9cfaa6e4478f92cd7d/content/renderer/media/user_media_client_impl.cc
[modify] https://crrev.com/82382cca8c9aa804acb7fd9cfaa6e4478f92cd7d/content/renderer/media/user_media_client_impl_unittest.cc

Project Member

Comment 9 by bugdroid1@chromium.org, Apr 11 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cf8ea8d590f1c89c2633c793a41bd31a85b3fe72

commit cf8ea8d590f1c89c2633c793a41bd31a85b3fe72
Author: guidou <guidou@chromium.org>
Date: Tue Apr 11 15:08:44 2017

Revert of Initialize default audio device ID with explicit device ID. (patchset #2 id:20001 of https://codereview.chromium.org/2812903002/ )

Reason for revert:
Patchset 2 restores the behavior I wanted to eliminate.

Original issue's description:
> Initialize default audio device ID with explicit device ID.
>
> This is more consistent with how video device IDs are specified and is
> also a small first step towards implementing the standard constraints
> algorithm for audio.
> This CL disables a misleading selector that allows switching the
> user-preferred device in the middle of a getUserMedia call.
> Since that selector does not affect the current getUserMedia call, it
> is better to have it disabled, which is already the case with video
> devices.
>
> BUG= 708081 
>
> Review-Url: https://codereview.chromium.org/2812903002
> Cr-Commit-Position: refs/heads/master@{#463624}
> Committed: https://chromium.googlesource.com/chromium/src/+/82382cca8c9aa804acb7fd9cfaa6e4478f92cd7d

TBR=hbos@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= 708081 

Review-Url: https://codereview.chromium.org/2813543005
Cr-Commit-Position: refs/heads/master@{#463634}

[modify] https://crrev.com/cf8ea8d590f1c89c2633c793a41bd31a85b3fe72/content/browser/renderer_host/media/media_stream_manager.cc
[modify] https://crrev.com/cf8ea8d590f1c89c2633c793a41bd31a85b3fe72/content/browser/renderer_host/media/media_stream_manager.h
[modify] https://crrev.com/cf8ea8d590f1c89c2633c793a41bd31a85b3fe72/content/renderer/media/user_media_client_impl.cc
[modify] https://crrev.com/cf8ea8d590f1c89c2633c793a41bd31a85b3fe72/content/renderer/media/user_media_client_impl_unittest.cc

Project Member

Comment 10 by bugdroid1@chromium.org, Apr 11 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/be26518ed4e8a2966c919a93b488689374b17d42

commit be26518ed4e8a2966c919a93b488689374b17d42
Author: guidou <guidou@chromium.org>
Date: Tue Apr 11 19:05:13 2017

Reland of Initialize default audio device ID with explicit device ID. (patchset #1 id:1 of https://codereview.chromium.org/2813543005/ )

Reason for revert:
Will attempt to reland by reverting changes in MSM and updating extensions test.

Original issue's description:
> Revert of Initialize default audio device ID with explicit device ID. (patchset #2 id:20001 of https://codereview.chromium.org/2812903002/ )
>
> Reason for revert:
> Patchset 2 restores the behavior I wanted to eliminate.
>
> Original issue's description:
> > Initialize default audio device ID with explicit device ID.
> >
> > This is more consistent with how video device IDs are specified and is
> > also a small first step towards implementing the standard constraints
> > algorithm for audio.
> > This CL disables a misleading selector that allows switching the
> > user-preferred device in the middle of a getUserMedia call.
> > Since that selector does not affect the current getUserMedia call, it
> > is better to have it disabled, which is already the case with video
> > devices.
> >
> > BUG= 708081 
> >
> > Review-Url: https://codereview.chromium.org/2812903002
> > Cr-Commit-Position: refs/heads/master@{#463624}
> > Committed: https://chromium.googlesource.com/chromium/src/+/82382cca8c9aa804acb7fd9cfaa6e4478f92cd7d
>
> TBR=hbos@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG= 708081 
>
> Review-Url: https://codereview.chromium.org/2813543005
> Cr-Commit-Position: refs/heads/master@{#463634}
> Committed: https://chromium.googlesource.com/chromium/src/+/cf8ea8d590f1c89c2633c793a41bd31a85b3fe72

# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= 708081 

Review-Url: https://codereview.chromium.org/2809043004
Cr-Commit-Position: refs/heads/master@{#463710}

[modify] https://crrev.com/be26518ed4e8a2966c919a93b488689374b17d42/content/renderer/media/user_media_client_impl.cc
[modify] https://crrev.com/be26518ed4e8a2966c919a93b488689374b17d42/content/renderer/media/user_media_client_impl_unittest.cc
[modify] https://crrev.com/be26518ed4e8a2966c919a93b488689374b17d42/extensions/browser/guest_view/web_view/web_view_media_access_apitest.cc

Status: Fixed (was: Assigned)
Project Member

Comment 12 by bugdroid1@chromium.org, Apr 22 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/18633fc39ce832de0cea59a4c7f4371144c407e0

commit 18633fc39ce832de0cea59a4c7f4371144c407e0
Author: guidou <guidou@chromium.org>
Date: Sat Apr 22 19:27:57 2017

Revert of Initialize default audio device ID with explicit device ID. (patchset #4 id:170001 of https://codereview.chromium.org/2809043004/ )

Reason for revert:
Causes  http://crbug.com/714386 

Original issue's description:
> Reland of Initialize default audio device ID with explicit device ID. (patchset #1 id:1 of https://codereview.chromium.org/2813543005/ )
>
> Reason for revert:
> Will attempt to reland by reverting changes in MSM and updating extensions test.
>
> Original issue's description:
> > Revert of Initialize default audio device ID with explicit device ID. (patchset #2 id:20001 of https://codereview.chromium.org/2812903002/ )
> >
> > Reason for revert:
> > Patchset 2 restores the behavior I wanted to eliminate.
> >
> > Original issue's description:
> > > Initialize default audio device ID with explicit device ID.
> > >
> > > This is more consistent with how video device IDs are specified and is
> > > also a small first step towards implementing the standard constraints
> > > algorithm for audio.
> > > This CL disables a misleading selector that allows switching the
> > > user-preferred device in the middle of a getUserMedia call.
> > > Since that selector does not affect the current getUserMedia call, it
> > > is better to have it disabled, which is already the case with video
> > > devices.
> > >
> > > BUG= 708081 
> > >
> > > Review-Url: https://codereview.chromium.org/2812903002
> > > Cr-Commit-Position: refs/heads/master@{#463624}
> > > Committed: https://chromium.googlesource.com/chromium/src/+/82382cca8c9aa804acb7fd9cfaa6e4478f92cd7d
> >
> > TBR=hbos@chromium.org
> > # Skipping CQ checks because original CL landed less than 1 days ago.
> > NOPRESUBMIT=true
> > NOTREECHECKS=true
> > NOTRY=true
> > BUG= 708081 
> >
> > Review-Url: https://codereview.chromium.org/2813543005
> > Cr-Commit-Position: refs/heads/master@{#463634}
> > Committed: https://chromium.googlesource.com/chromium/src/+/cf8ea8d590f1c89c2633c793a41bd31a85b3fe72
>
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG= 708081 
>
> Review-Url: https://codereview.chromium.org/2809043004
> Cr-Commit-Position: refs/heads/master@{#463710}
> Committed: https://chromium.googlesource.com/chromium/src/+/be26518ed4e8a2966c919a93b488689374b17d42

TBR=mek@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG= 708081 , 714386 

Review-Url: https://codereview.chromium.org/2829403002
Cr-Commit-Position: refs/heads/master@{#466550}

[modify] https://crrev.com/18633fc39ce832de0cea59a4c7f4371144c407e0/content/renderer/media/user_media_client_impl.cc
[modify] https://crrev.com/18633fc39ce832de0cea59a4c7f4371144c407e0/content/renderer/media/user_media_client_impl_unittest.cc
[modify] https://crrev.com/18633fc39ce832de0cea59a4c7f4371144c407e0/extensions/browser/guest_view/web_view/web_view_media_access_apitest.cc

Project Member

Comment 13 by bugdroid1@chromium.org, Apr 25 2017

Labels: merge-merged-3071
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4f7111ba056d63c43cc30745302e12ff31d0cc17

commit 4f7111ba056d63c43cc30745302e12ff31d0cc17
Author: Guido Urdaneta <guidou@chromium.org>
Date: Tue Apr 25 08:32:03 2017

Revert of Initialize default audio device ID with explicit device ID. (patchset #4 id:170001 of https://codereview.chromium.org/2809043004/ )

Reason for revert:
Causes  http://crbug.com/714386 

Original issue's description:
> Reland of Initialize default audio device ID with explicit device ID. (patchset #1 id:1 of https://codereview.chromium.org/2813543005/ )
>
> Reason for revert:
> Will attempt to reland by reverting changes in MSM and updating extensions test.
>
> Original issue's description:
> > Revert of Initialize default audio device ID with explicit device ID. (patchset #2 id:20001 of https://codereview.chromium.org/2812903002/ )
> >
> > Reason for revert:
> > Patchset 2 restores the behavior I wanted to eliminate.
> >
> > Original issue's description:
> > > Initialize default audio device ID with explicit device ID.
> > >
> > > This is more consistent with how video device IDs are specified and is
> > > also a small first step towards implementing the standard constraints
> > > algorithm for audio.
> > > This CL disables a misleading selector that allows switching the
> > > user-preferred device in the middle of a getUserMedia call.
> > > Since that selector does not affect the current getUserMedia call, it
> > > is better to have it disabled, which is already the case with video
> > > devices.
> > >
> > > BUG= 708081 
> > >
> > > Review-Url: https://codereview.chromium.org/2812903002
> > > Cr-Commit-Position: refs/heads/master@{#463624}
> > > Committed: https://chromium.googlesource.com/chromium/src/+/82382cca8c9aa804acb7fd9cfaa6e4478f92cd7d
> >
> > TBR=hbos@chromium.org
> > # Skipping CQ checks because original CL landed less than 1 days ago.
> > NOPRESUBMIT=true
> > NOTREECHECKS=true
> > NOTRY=true
> > BUG= 708081 
> >
> > Review-Url: https://codereview.chromium.org/2813543005
> > Cr-Commit-Position: refs/heads/master@{#463634}
> > Committed: https://chromium.googlesource.com/chromium/src/+/cf8ea8d590f1c89c2633c793a41bd31a85b3fe72
>
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG= 708081 
>
> Review-Url: https://codereview.chromium.org/2809043004
> Cr-Commit-Position: refs/heads/master@{#463710}
> Committed: https://chromium.googlesource.com/chromium/src/+/be26518ed4e8a2966c919a93b488689374b17d42

TBR=mek@chromium.org
BUG= 708081 , 714386 

Review-Url: https://codereview.chromium.org/2829403002
Cr-Commit-Position: refs/heads/master@{#466550}
(cherry picked from commit 18633fc39ce832de0cea59a4c7f4371144c407e0)

Review-Url: https://codereview.chromium.org/2837873004 .
Cr-Commit-Position: refs/branch-heads/3071@{#194}
Cr-Branched-From: a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641}

[modify] https://crrev.com/4f7111ba056d63c43cc30745302e12ff31d0cc17/content/renderer/media/user_media_client_impl.cc
[modify] https://crrev.com/4f7111ba056d63c43cc30745302e12ff31d0cc17/content/renderer/media/user_media_client_impl_unittest.cc
[modify] https://crrev.com/4f7111ba056d63c43cc30745302e12ff31d0cc17/extensions/browser/guest_view/web_view/web_view_media_access_apitest.cc

Labels: TE-Verified-M59 TE-Verified-59.0.3071.29
Verified this issue on Mac OS 10.12.4 using chrome latest Beta M59 #59.0.3071.29 by following steps mentioned in the original comment. Observed the options are enabled under camera icon and able to change the input devices as expected. Hence adding TE-Verified label.
708081.mp4
471 KB View Download

Sign in to add a comment