https://chromium.googlesource.com/chromium/src/+/28a46c315b7a01905c6509ec51b572cb89209a50 causes this.
I am investigating why, because that patch should not affect the UI.
The bug is not too serious because that selector does not actually select the camera to be used and should probably be removed. However, it's important to know why a change in device selection has this effect on the UI.

The reason this happens is that the new algorithm selects a device based on the constraints and specifies it in the IPC to the browser when generating the stream, while the old algorithm only sends a device ID to the browser if one is explicitly indicated in the constraints.

The UI dialog uses this to enable/disable the selector.
The selector is meaningless anyway because it does not allow selecting the device to be used by the getUserMedia call that triggered the dialog, but to select the default device to be used in subsequent calls to getUserMedia.

We can try to restore the old behavior, but I don't think it's worth it. This selector should disappear once the UI is updated (issue 556542). I would argue that the new behavior is actually better.

The default camera can still be changed in Content Settings.

Marking as WontFix. Feel free to reopen if you think it is important to address this.

Hmm. I am not sure if the selector is meaningless. Even if it only takes effect after reloading the page, it seemed useful to me (especially before I learned that the default device can also be changed in Content Settings).

Unfortunately, it seems that the default camera setting is no longer taken into account (which would be a different issue than the one originally reported). I tried to switch between cameras by changing the default and reloading the page, but I always only get the first camera. Note, that in the getUserMedia request I am not specifying any constraints other than audio:true and video:true.

Could you take another look and check if you get the same behavior?

The selector is indeed meaningless in the sense that what it does (changing the default device for future calls) is not what the UI suggests.
Having it disabled is better because it becomes an informative label indicating the device currently in use.

There is indeed a bug with choosing the default device when --use-fake-device-for-media-stream in on due to an additional switch I added recently to facilitate changing the default device in tests. I'll have it fixed soon.

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

commit 2c5c012360a9213b6895ce6c79fa62f941c2bd20
Author: guidou <guidou@chromium.org>
Date: Wed Feb 22 11:18:31 2017

If no command-line default device is provided, fall back to reading it
from preferences instead of acting as if there was no default device.

This affects only the case when the command-line flag "--use-fake-device-for-media-stream" is supplied.

BUG= 693746 

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

[modify] https://crrev.com/2c5c012360a9213b6895ce6c79fa62f941c2bd20/content/browser/media/media_devices_util.cc

revision #451995 fixes the issue in comment #6.
chfremer@: can you verify?

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

commit 0e05c9b817a75ba6fa1d24d2a9921121ccae80f9
Author: guidou <guidou@chromium.org>
Date: Wed Feb 22 14:16:02 2017

Revert of Fall back to default media device from preferences if no default is supplied from the command line. (patchset #1 id:20001 of https://codereview.chromium.org/2707033003/ )

Reason for revert:
Speculative revert to see if this causes https://build.chromium.org/p/chromium.webrtc/builders/Mac%20Tester/builds/65668/ to time out in a WebRTC-related test.

Original issue's description:
> If no command-line default device is provided, fall back to reading it
> from preferences instead of acting as if there was no default device.
>
> This affects only the case when the command-line flag "--use-fake-device-for-media-stream" is supplied.
>
> BUG= 693746 
>
> Review-Url: https://codereview.chromium.org/2707033003
> Cr-Commit-Position: refs/heads/master@{#451995}
> Committed: https://chromium.googlesource.com/chromium/src/+/2c5c012360a9213b6895ce6c79fa62f941c2bd20

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

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

[modify] https://crrev.com/0e05c9b817a75ba6fa1d24d2a9921121ccae80f9/content/browser/media/media_devices_util.cc

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

commit c05af3853cd658ebc009b0a351267622ee77ecb3
Author: guidou <guidou@chromium.org>
Date: Wed Feb 22 17:15:02 2017

Reland of Fall back to default media device from preferences if no default is supplied from the command line. (patchset #1 id:1 of https://codereview.chromium.org/2713653002/ )

Reason for revert:
Will try to reland with an update to the broken test.

Original issue's description:
> Revert of Fall back to default media device from preferences if no default is supplied from the command line. (patchset #1 id:20001 of https://codereview.chromium.org/2707033003/ )
>
> Reason for revert:
> Speculative revert to see if this causes https://build.chromium.org/p/chromium.webrtc/builders/Mac%20Tester/builds/65668/ to time out in a WebRTC-related test.
>
> Original issue's description:
> > If no command-line default device is provided, fall back to reading it
> > from preferences instead of acting as if there was no default device.
> >
> > This affects only the case when the command-line flag "--use-fake-device-for-media-stream" is supplied.
> >
> > BUG= 693746 
> >
> > Review-Url: https://codereview.chromium.org/2707033003
> > Cr-Commit-Position: refs/heads/master@{#451995}
> > Committed: https://chromium.googlesource.com/chromium/src/+/2c5c012360a9213b6895ce6c79fa62f941c2bd20
>
> TBR=tommi@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG= 693746 
>
> Review-Url: https://codereview.chromium.org/2713653002
> Cr-Commit-Position: refs/heads/master@{#452035}
> Committed: https://chromium.googlesource.com/chromium/src/+/0e05c9b817a75ba6fa1d24d2a9921121ccae80f9

TBR=tommi@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG= 693746 

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

[modify] https://crrev.com/c05af3853cd658ebc009b0a351267622ee77ecb3/chrome/browser/media/webrtc/webrtc_apprtc_browsertest.cc
[modify] https://crrev.com/c05af3853cd658ebc009b0a351267622ee77ecb3/content/browser/media/media_devices_util.cc

I confirmed that the default setting is now picked up on a fresh build from the tip of tree.

Thanks!

I think it'd still be important to update the UI in that case to not show a disabled dropdown. The dropdown style really suggests it could be possible to update from there. 

In addition (and I'll create a separate ticket for that), camera setting is also not working in the app settings. Simple example is that calling mediaDevices.enumerateDevices returns defaults for audioinput and audiooutput but not for videoinput.

Note that the default entries in enumerateDevices() are system defaults, which are not necessarily the same as the user defaults stored in content settings.
There is no system default for cameras in any of the platforms we support, so there are no default entries for cameras in the results of enumerateDevices().

When a getUserMedia() request does not specify a device, Chrome chooses the user-default device, if possible. If not, the system default device (for audio) is used.

There are already bugs filed to improve the permission UI for media devices.
For example, Bug 556542 and bug 625769.

Guys, having a disabled dropdown as a "hint" of the current camera is misleading. I've been seraching for a "fix" for hours becaue obviously I've fallen to the same trap like many other people, that a disabled dropdown is actually a bug. There are numerous forums and threads with support issues that involve "why is the camera selection dropdown disabled" all over the internet. As a 16 years software developer myself, I think I speak for a very large user group when I say that this is seen as a BUG, not as a "hint". The expected behaviour, as reported by numerous other people everywhere, would have been that the dropdown was enabled and the user could actively switch between cameras. Thar was my impression as well until reaching this thread. Please fix this.

yers please, i cannot select the default camera it just picks one of them, not the correct one. it doesnt listen to the one i set on the chrome://settings/content/camera page

#21: Having a disabled dropdown to indicate the camera is indeed a UI bug, and we have several bugs filed to improve the UI (see bug 556542, bug 453698 and bug 625769, for example). For the particular issue of the disabled dropdown the fix should probably be to eliminate the dropdown and substitute for a string.

#22: Chrome does not pick cameras at random. It picks them based on what the application requests via constraints. The one in chrome://settings is used when no constraints are supplied or if constraints can be satisfied by multiple cameras.
If you can reproduce a case where this is not what happens, please file a bug so that we can look at it.