It's definitely this change: https://chromium.googlesource.com/chromium/src/+/08fa67b0f718b342b8c47725f2018c63ade8b699.

We will probably have to updated TestRTC and adapter.js for this.

Forgot to mention that I will take a look at those today.

In my CL,
  [CallWith=ExecutionContext, LegacyInterfaceTypeChecking] void getStats(RTCStatsCallback successCallback, [Default=Undefined] optional MediaStreamTrack selector);
Changed into:
  [CallWith=ScriptState] Promise<void> getStats(RTCStatsCallback successCallback, optional MediaStreamTrack? selector);

It still expects two arguments of the same types but it no longer has [LegacyInterfaceTypeChecking] and [Default=Undefined]. I believe this change was necessary when overloading getStats (which I did by adding a promise-based getStats).
In adapter.js:238, getStats is called with arguments "getStats(successCallback, rejectCallback)". We don't and never did support a rejectCallback, so I'm guessing that the [LegacyInterfaceTypeChecking] and [Default=Undefined] saw that rejectCallback didn't match and turned it into an undefined value instead? Otherwise this shouldn't have worked in the first place.

My CL wasn't suppose to break existing usage but in this case it did. If it failed because we were trying to call it with unexpected arguments already then I think it's fair to say that the calling place should be updated and that we don't need to accommodate for calling cases such as this? Otherwise overloading getStats probably gets messy again.

I was able to re-add LegacyInterfaceTypeChecking and overloading still works: https://codereview.chromium.org/2198123002/

hbos@ - I no longer see the info overlay in apprtc calls (by pressing "i" during the call). 
Is this related to your change as well?

This issue is also observed on Chrome OS.

#7 srnayanan@ - Yes, same reason.

I have confirmed that this is the cause and that my CL fixes it. It's in the CQ.

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

commit 7a4e83b57886f79649c47c8f3476ac961f291d07
Author: hbos <hbos@chromium.org>
Date: Tue Aug 02 10:38:19 2016

RTCPeerConnection.getStats gets LegacyInterfaceTypeChecking.

This tag was removed in https://codereview.chromium.org/2156063002/
which caused a regression ( crbug.com/632457 ). This CL re-adds it to
solve that regression. The generated bindings code is able to
call the correct overloaded getStats function with or without it.

LegacyInterfaceTypeChecking means any (nonsense) argument can be passed
as the second parameter and if its not a MediaStreamTrack it is
interpreted as null. This was something adapter.js relied on.

BUG= 632457 ,  627816 

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

[modify] https://crrev.com/7a4e83b57886f79649c47c8f3476ac961f291d07/third_party/WebKit/LayoutTests/fast/peerconnection/RTCPeerConnection-stats-expected.txt
[modify] https://crrev.com/7a4e83b57886f79649c47c8f3476ac961f291d07/third_party/WebKit/LayoutTests/fast/peerconnection/RTCPeerConnection-stats.html
[modify] https://crrev.com/7a4e83b57886f79649c47c8f3476ac961f291d07/third_party/WebKit/Source/modules/peerconnection/RTCPeerConnection.idl

Fixed, it works.

Issue 633742 has been merged into this issue.

Looks good in M54 Canary 54.0.2817.0 - No JS errors

Tested sample pages -
https://test.webrtc.org/
https://webrtc.github.io/samples/src/content/peerconnection/audio/
https://webrtc.github.io/samples/src/content/peerconnection/bandwidth/

The info overlay in apprtc calls (by pressing "i" during the call) is back, with stats! 

Awesome, thanks for testing :)