We've now tested this under Windows, too. Same problem here, the browser tab becomes completely unresponsive.

Something I forgot: When the freeze happens, it is not even possible to click on any user interface element inside the frozen tab.

Another important thing to note is that the problem only exists if Chrome is the browser that joins an existing WebRTC session, i.e. if the peer is already streaming. If Chrome initiates the hand-shake, everything works fine.

In all cases, there are no error messages in the Inspector.

Tested with iOS as peer. Same problem. If iOS initiates the session and Chrome on macOS joins, the tab freezes. If Chrome starts the session, it works.

After some debugging, I found out that the problem occurs when Chrome receives a remote offer and I then try to add the local stream to the peer connection via an RTCPeerConnection#addStream call, e.g.

peerConnection.addStream(myStream);

As soon as this is called inside the remote offer handler, the tab freezes immediately.

Funnily, if I place a

debugger; 

line right before the call and then execute the addStream() call right after the debugger stops, everything works as expected. But as soon as I remove the debugger call and let the code run immediately, the tab freezes.

It looks as if the browser runs into a timing problem / racing condition inside the addStream() method.

The call also works if I place it inside a setTimeout() to run it async.

can you provide a fiddle to reproduce the problem?
https://jsfiddle.net/ug5tugnL/ seems to work fine but there might be differences from what you do.

hbos@, can you take a look since this apparently concerns addStream()?

What is the "remote offer handler"? What event are you listening to?

addStream blocks the main thread ("javascript and tab thread") until the webrtc signaling thread as performed addStream in lower layers. Sounds like there might be a deadlock, but I don't know of anything on the webrtc signaling thread that would wait for the main thread.

How easy is it to repro this?

Is it possible to construct a repro jsfiddle?

Also, have you tried if this can be reproduced on latest Canary?

I'm experiencing the exact same problem around the addStream command. 
Tested on Windows 7, 10 and Linux Mint.
I also noticed that it only seems to occur starting with Chrome version 63 (tested with 63.0.3239.132). 
Beta (64.0.3282.119) seems to have the same problem.
58.0.3029.96, 62.0.3202.75 and Dev (65.0.3325.18), however, are not freezing.
As noted before, timing seems to be a relevant factor. Setting a breakpoint or putting the addStream into a setTimeout prevents the freeze.

When do you call addStream? I don't have enough information to reproduce and fippo's jsfiddle is working.

It sounds like the webrtc signaling thread is blocked on doing something which has been posted to the main thread and is in-queue, but calling addStream blocks the main thread.

When you setTimeout that allows the main thread to execute all queued tasks before it does the addStream call, which no longer is blocked because the webrtc signaling thread was unblocked.

it would also be interesting to hear if moving addStream before setRemoteDescription (and ignoring any negotiationneeded if that is used) is a valid workaround.

chrome://webrtc-internals logs might be useful too, even though less than a reproduction fiddle.

Moving addStream before setRemoteDescription seems to actually have done the trick! Thank you!

I have not yet been able to create a fiddle but have attached a WebRTC internals dump if that helps.

The flow on my side used to be as follows:
- Got offer from remote
- Get local stream
- Create RTCPeerConnection
- Register callback handlers
- set remote description
- addStream
-> Freeze

Deleted: webrtc_internals_dump.txt 3.1 KB

webrtc_internals_dump.txt 3.1 KB View Download

I was able to reproduce the freeze with this fiddle, which quite well resembles the way I'm handling an incoming offer in my client: https://jsfiddle.net/mbhjkevx/1/

hbos: taylor said it might be https://bugs.chromium.org/p/chromium/issues/detail?id=736725#c6

Yes, sounds likely to be a duplicate of  issue 736725 .

hbos - looks like the fix made it to M65 but not to M64 that's being pushed to stable now. Would it make sense to ask for a merge to M64 assuming there will be further updates?

I've verified that this is indeed a duplicate and fixed by https://chromium-review.googlesource.com/c/chromium/src/+/868656. Thanks for the repro fiddle!

Tip of tree: Not reproducible.
64.0.3282.99: Reproducible.
64.0.3282.99 with patch applied: Not reproducible.

Discussing merge into stable at  issue 736725 .

Thanks a lot for that very quick problem solution. Highly appreciated!