- From: Jan-Ivar Bruaroey via GitHub <noreply@w3.org>
- Date: Thu, 26 Feb 2026 01:53:33 +0000
- To: public-webrtc@w3.org
jan-ivar has just created a new issue for https://github.com/w3c/webrtc-pc: == Should garbage collecting RTCPeerConnection be observable? == In https://github.com/w3c/webrtc-pc/issues/2624 we decided garbage collecting non-closed RTCDataChannels shouldn't be observable. Our solution was for RTCPeerConnection to hold strong references to them. But that begs the next question: what holds RTCPeerConnection alive? In [RTCDataChannel-GC.html](https://github.com/web-platform-tests/wpt/blob/5f4ffc862d1108985440e39f487c9b1a3ea4a658/webrtc/RTCDataChannel-GC.html), JS is holding no references to `pc2` past [line 37](https://github.com/web-platform-tests/wpt/blob/5f4ffc862d1108985440e39f487c9b1a3ea4a658/webrtc/RTCDataChannel-GC.html#L37). Yet Safari and Chrome keep it alive; Firefox does not. Who's right? `pc2` has one event handler for `icecandidate` events, but those likely can't fire this late (assuming gatheringState is "complete"). The two options I see are: 1. clarify pc should NOT be GC'ed if connected and pc close through document unload is remotely observable through a data channel, or 2. add a note that GC might be remotely observable (or through a local loop) using a data channel Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/3090 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 26 February 2026 01:53:34 UTC