Consider merging https://chromium.googlesource.com/chromium/blink/+/d2c15b9a56ace790cbf0e71507034ebd64da0ff6 The spec states that: "A Window object has a strong reference to any RTCPeerConnection objects created from the constructor whose global object is that Window object." Which means that RTCPC objects should never be garbage collected.
That's a bit mysterious. What is the observable symptom this bug fixes?
(In reply to comment #1) > That's a bit mysterious. What is the observable symptom this bug fixes? I asked Adam Bergkvist, one of the spec authors, about that section of the spec and he said: The RTCPeerConnection Garbage Collection section doesn't make sense to me either. I don't think that particular section has been touched since the w3c forked the WHATWG WebRTC spec. My initial thinking is that the RTCPeerConnection object should be protected when certain listeners are attached; similar to RTCDataChannel [1] (which mimics WebSocket). So I am marking this as WONTFIX and we can revisit the issue when the spec is updated.
(In reply to comment #2) > (In reply to comment #1) > > That's a bit mysterious. What is the observable symptom this bug fixes? > > I asked Adam Bergkvist, one of the spec authors, about that section of the spec and he said: > > The RTCPeerConnection Garbage Collection section doesn't make sense to me either. > I don't think that particular section has been touched since the w3c forked the > WHATWG WebRTC spec. > > My initial thinking is that the RTCPeerConnection object should be protected when > certain listeners are attached; similar to RTCDataChannel [1] (which mimics WebSocket). > > So I am marking this as WONTFIX and we can revisit the issue when the spec is updated. Just to throw a wrench in the mix, it looks like the blink patch doesn't actually do what it states, it looks like what it does is change things so RTCPeerConnections won't get GC'd while the connection is not stopped. We may want that behavior, but I am not sure.