New issue
Advanced search Search tips

Issue 746973 link

Starred by 2 users

Issue metadata

Status: Duplicate
Merged: issue 734078
Owner:
Closed: Jul 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

audioTrack.getSettings() always returns a fake {deviceId: "audio device ID"}

Reported by ibc@aliax.net, Jul 20 2017

Issue description

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

Steps to reproduce the problem:
1.  Open https://jsfiddle.net/ibcaliax/zvfnz9bf/ and the browser DevTool console.

What is the expected behavior?
Both audioTrack.getSettings().deviceId and videoTrack.getSettings().deviceId should provide consistent values.

AFAIK, since the user accepted the getUserMedia prompt, track.getSettings() should provide full and real information (rather than face ids). In fact, the enumerateDevices call clearly shows proper info about the multimedia devices.

What went wrong?
audioTrack.getSettings().deviceId returns "audio device ID" (which does not match any real deviceId) while videoTrack.getSettings().deviceId returns a real deviceId (same as in the result of enumerateDevices).

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 59.0.3071.115  Channel: stable
OS Version: OS X 10.12.5
Flash Version: 

In Canary M61, audioTrack.getSettings().deviceId returns "default" instead, so this may be already fixed.
 
Labels: Needs-Triage-M59 Needs-Bisect
Cc: jmukthavaram@chromium.org
Labels: -Type-Bug -Pri-2 -Needs-Bisect -Needs-Triage-M59 hasbisect-per-revision M-61 OS-Linux OS-Windows Pri-1 Type-Bug-Regression
Owner: guidou@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce the issue on Mac 10.12.5 using chrome stable#59.0.3071.115 & working as intended in Canary#61.0.3162.0.

audioTrack.getSettings().deviceId returns "default" in Devtools->Console as mentioned in comment#0.As it is reverse bisect issue, providing the below reverse bisect info:

Manual bisect info:
------------------
Good-61.0.3151.4-Revision-484781
Bad-61.0.3150.0-Revision-484424

Reverse Per revision bisect info:
---------------------------------
You are probably looking for a change made after 484599 (known good), but no later than 484600 (first known bad).
CHANGELOG URL:
The script might not always return single CL as suspect as some perf builds might get missing due to failure.
https://chromium.googlesource.com/chromium/src/+log/667c0bb37390dc1f4e336151719e30537c1d746d..43855d4106b745fa975172372ece8b0492be5fda

Possible suspect:
----------------
https://chromium.googlesource.com/chromium/src/+/43855d4106b745fa975172372ece8b0492be5fda

guidou@Could you please take a look and reassign to the right owner if it is not related to your change.

Note :
On Windows 7 & Ubuntu 14.04 behavior:
1.Canary-61.0.3162.0-Working as intended
2.Stable-59.0.3071.115- Uncaught exception error displayed once user runs fiddle

Thanks..!!


Comment 3 by guidou@chromium.org, Jul 21 2017

Mergedinto: 734078
Status: Duplicate (was: Assigned)
This was recently fixed in 61. See  bug 734078 .

Comment 4 by ibc@aliax.net, Jul 21 2017

Nice, thanks.

Sign in to add a comment