Issue seen in M52 builds in Win, Mac, Linux as well. 

Bisect info -

You are probably looking for a change made after 386755 (known good), but no later than 386769 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/db9739931a735e8ea3c502dd9bc9890aab175521..ed75dc7053dc072bdd0e72f64a869d59ec587f4b

Apprtc loopback call javascript logs and video for bug description : https://pantheon.corp.google.com/storage/browser/chromiumos-test-logs/bugfiles/cr/614181/

jansson@, can you take a look? There aren't any WebRTC CLs in the culprit range linked in #1, but from that comment and the original report, it's clear that a Chrome change appears to be to blame, as opposed to a change in apprtc.

I took a look at the AppRTC code for the New Room logic and I cannot see anything there that could cause this behavior (executes som JS, e.g. it hides the bottom bar [1] with the buttons but then stops [2] (based on the fact the room selection UI is not shown) without printing any errors). It seems like something in Chrome does NOT process some parts of https://github.com/webrtc/apprtc/blob/master/src/web_app/js/appcontroller.js#L185 properly (before https://github.com/webrtc/apprtc/blob/master/src/web_app/js/appcontroller.js#L189 since it would show the room selection UI).

[1] https://github.com/webrtc/apprtc/blob/master/src/web_app/js/appcontroller.js#L390
[2] https://github.com/webrtc/apprtc/blob/master/src/web_app/js/appcontroller.js#L391

Tommi, here's another bug that a WebRTC page tickles, but which doesn't seem to be caused by WebRTC code in Chrome. Do you have a suggestion for an appropriate component or owner we can reassign this bug to? 

Guido - could the srcObject change have anything to do with this?

I don't think srcObject should cause this kind of problem, but I'll investigate.

The srcObject CL causes the problem. If I revert it locally, the problem disappears. However, it's strange that the presence of the srcObject field is causing this kind of UI problem. I'll take a look at the AppRTC and adapter.js code to see if I can find something there. 

Adapter.js shimming code (which should not be executed due to srcObject exists): https://github.com/webrtc/adapter/blob/master/src/js/chrome/chrome_shim.js#L56-L96

Adapter.js attach/reattach stream code (to be deprecated but still used):
https://github.com/webrtc/adapter/blob/master/src/js/chrome/chrome_shim.js#L251-L271

AppRTC code executed when clicking new room:
https://github.com/webrtc/apprtc/blob/master/src/web_app/js/appcontroller.js#L388

The strange part is that if you look at the code that is supposed to be executed in apprtc, there is nothing touching srcObject in this.deactivate_(this.rejoinDiv_), this.hide_(this.rejoinDiv_) and this.showRoomSelection_()). 

Unless the issue has already happened when hanging up? After hanging up I can see that src is = '' while srcObject is still pointing to the MediaStream (document.querySelector('video')).
Code here:
https://github.com/webrtc/apprtc/blob/master/src/web_app/js/call.js#L113-L218

I looked at the code with jansson@ and it looks like the problem is that some functions are using srcObject (via the shim) to assign, but src to cleanup.

See
https://github.com/webrtc/apprtc/blob/master/src/web_app/js/appcontroller.js#L318-L357

It uses reattachMediaStream to set the source and src to clear it, but reattachMediaStream internally uses srcObject.

https://github.com/webrtc/adapter/blob/master/src/js/chrome/chrome_shim.js#L252-L271

Before M52, the shim translated srcObject to src so clearing using src worked.

jansson@ is updating apprtc's code to use srcObject.

Fixing in https://github.com/webrtc/apprtc/pull/311. Will post back here when it's pushed to prod.

Fixed in https://github.com/webrtc/apprtc/pull/311 and verified on appr.tc using Chrome 52.0.2743.17.

Tested AppRTC loopback and peer2peer calls on chrome device Gnawty with 52.0.2743.32 / 8350.21.0 beta and verified that new AppRTC calls can be started after leaving current call.