Closed
Bug 881337
Opened 12 years ago
Closed 9 years ago
onclose on data channels will not fire on desktop in a desktop to android call where FxAndroid gets killed in the background
Categories
(Core :: WebRTC: Signaling, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: jsmith, Unassigned)
Details
(Whiteboard: [WebRTC][blocking-webrtc-])
Attachments
(1 file)
(deleted),
text/html
|
Details |
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•12 years ago
|
Blocks: android-webrtc
Reporter | ||
Comment 1•12 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•12 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•12 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: android-webrtc
Whiteboard: [WebRTC][android-webrtc?] → [WebRTC][blocking-webrtc-]
Comment 4•11 years ago
|
||
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.
Comment 5•9 years ago
|
||
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: 9 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•