The correct version is: Version 53.0.2748.0 canary (64-bit)

boris@, can you retry your steps with today's canary (53.0.2749.2)? I'm unable to reproduce the error when I follow steps 1. and 2. in your original report.

I cannot reproduce it on 53.0.2749.2. However, I am running into another issue with deviceId, this time when combined with constraints.

This following works (pops up the user consent window):
constraints = {audio: { deviceId: "default" }};
navigator.webkitGetUserMedia(constraints, function(s){console.log('success', s);}, function(e){console.log('error', e);})

Changing the constraints to:
constraints = {audio: { mandatory: {}, deviceId: "default" }};
or
constraints = {audio: { optional: [], deviceId: "default" }};
results in the following error:
"Mailformed constraint: Cannot use both optional/mandatory and specific or advanced constraints."

This syntax works in stable, and I think it used to work in Canary until recently. Is this intentional?

hta@ - can you answer the question in #4? 

mandatory/optional has been removed in favour of the new style syntax as the error message you see hints at.

Some examples can found in our samples:
- https://github.com/webrtc/samples/blob/gh-pages/src/content/devices/input-output/js/main.js#L99
- https://github.com/webrtc/samples/blob/gh-pages/src/content/peerconnection/constraints/js/main.js#L98
- https://github.com/webrtc/samples/blob/gh-pages/src/content/getusermedia/resolution/js/main.js#L37

Also note we have a shim that converts old style to new style among other things.
https://github.com/webrtc/adapter

I take it you're running with the experimental flag on? This feature is hidden behind a flag.

Re audio: { deviceId: "default" }:

This is a "naked value constraint". Support for parsing those values landed in Chrome tip-of-tree yesterday: https://codereview.chromium.org/1977513004/

Re constraints = {audio: { mandatory: {}, deviceId: "default" }}:

This mixes old-style constraints (mandatory/optional, 2013 version of the spec) with direct values (2014 and later versions of the W3C spec). What to do in this case isn't defined in either version of the spec, so we forbid it.

See https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/modules/mediastream/MediaTrackConstraintSet.idl&q=mandatory%20file:idl&sq=package:chromium&type=cs&l=25 for the precise IDL declaration.

I expect that your example is descended from code that was intended to work on both Firefox (which supports the new-style constraints) and Chrome (which supported only the old-style constraints), and that half your constraints were ignored on each platform.

Sticking to the standard style and using adapter.js is probably a better solution.

I'm marking this "fixed" since support for parsing this has landed (yesterday!); I suppose I could also choose "wontfix" for the examples in comment #4, but that's not where this bug started.

That explain it. Thank you!