Closed Bug 881337 Opened 6 years ago Closed 4 years ago
onclose on data channels will not fire on desktop in a desktop to android call where Fx
Android gets killed in the background
Desktop: 6/10/2013 Nightly Android: Galaxy Nexus, Android 4.2, 6/10/2013 Nightly STR 1. Go to http://mysecondwebrtc.appspot.com/ on FxAndroid Nightly 2. Go to http://mysecondwebrtc.appspot.com/ on Desktop Firefox Nightly 3. Register the remote client from FxAndroid on to Desktop Firefox 4. Wait until the data channel status turns open for Desktop Firefox and FxAndroid 5. After open is established, kill the FxAndroid process Expected On Desktop, we should see onclose fire on the data channel. Actual onclose fails to fire on desktop.
Randell - Any thoughts on this? How do we handle the case where one of the peer's processes gets killed in the background? Note - this situation will also be a problem on b2g as well.
Talking with Randell - What should happen here is desktop should eventually time out over a certain set of time, which results in the connection being declared failed with the connection closed. On this case, the connection should be closed, resulting in onclose firing.
Eric mentioned that this use case in this bug currently does not work. Likely platform independent then, so removing android tracking bug.
No longer blocks: android-webrtc
Whiteboard: [WebRTC][android-webrtc?] → [WebRTC][blocking-webrtc-]
I ran into this problem with a slightly different use case, rather Desktop <-> Desktop. The onclose Event is not fired when the other Browser instance is killed (using 'kill -9'). This HTML file demonstrates the case. To reproduce follow these steps: 1. Open webrtc-dc-close.html in two browser instances 2. Click on "Create Offer" in instance A 3. Paste the resulting offer into the upper textarea of instance B 4. Click "Accept offer" in instance B 5. Copy the resulting answer into the upper textarea of instance A 6. instance B should now show "on data channel" 7. kill -9 PID_OF_INSTANCE_A This will result in instance A displaying "DC closed after X ms". In my tests X was a value between 704,000 and 711,000 but this may vary I guess. What should happen is that additional to the message above instance B should show "DC closed" which it does when you close instance A normally but doesn't when you KILL instance A.
SCTP will eventually kill the connection, but this can take a while. We don't clearly fire events or close things on failure of the other end to respond to consent checks/etc yet. THis is fundamental; if an app needs a faster failure detection, it should implement it's own heartbeat on top of DataChannels.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.