onclose on data channels will not fire on desktop in a desktop to android call where FxAndroid gets killed in the background

RESOLVED WONTFIX

Status

()

Core
WebRTC: Signaling
RESOLVED WONTFIX
5 years ago
3 years ago

People

(Reporter: jsmith, Unassigned)

Tracking

Trunk
ARM
Android
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [WebRTC][blocking-webrtc-])

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
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.
(Reporter)

Updated

5 years ago
Blocks: 750010
(Reporter)

Comment 1

5 years ago
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.
Flags: needinfo?(rjesup)
Whiteboard: [WebRTC][android-webrtc?]
(Reporter)

Comment 2

5 years ago
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.
Flags: needinfo?(rjesup)
(Reporter)

Comment 3

5 years ago
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: 750010
Whiteboard: [WebRTC][android-webrtc?] → [WebRTC][blocking-webrtc-]
Created attachment 819712 [details]
Desktop <-> Desktop case

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
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.