Last Comment Bug 861721 - After setting up a peer connection handshake with data channels, if I send a message while offline, then come back online, I will never be able to send messages ever again
: After setting up a peer connection handshake with data channels, if I send a ...
Status: NEW
:
Product: Core
Classification: Components
Component: WebRTC: Networking (show other bugs)
: Trunk
: All All
P5 normal 55 (vote)
: ---
Assigned To: Randell Jesup [:jesup] (needinfo me)
: Jason Smith [:jsmith]
: Nils Ohlmeier [:drno]
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-04-14 20:06 PDT by Jason Smith [:jsmith]
Modified: 2018-04-07 15:52 PDT (History)
2 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
webrtc/webaudio+


Attachments
Test Case (7.50 KB, text/html)
2013-04-14 20:07 PDT, Jason Smith [:jsmith]
no flags Details

Description User image Jason Smith [:jsmith] 2013-04-14 20:06:48 PDT
STR:

1. Load the attached test case while online
2. Setup the handshake online
3. Kill the network
4. Send a message with one character for the local DC
5. Come back online
6. Try sending a message again with one character

Expected:

Debatable. If the connection between two data channels is lost, I'd potentialy expect onclose to fire to indicate that the channels have been closed due to loss of network connectivity temporarily. If it's possible technically to still continue, then I'd expect the message to be sent when you come back online.

Actual:

All sent messages are lost when you come back online. No onclose event fires either. So if a user loses network connectivity after a handshake is established between a local and remote peer with data channels, the connection is permanently lost when we lose connectivity. 

So why aren't we telling the developer the connection was lost permanently? Why can't we send messages again when we come back online?
Comment 1 User image Jason Smith [:jsmith] 2013-04-14 20:07:11 PDT
Created attachment 737335 [details]
Test Case
Comment 2 User image Randell Jesup [:jesup] (needinfo me) 2013-04-14 23:37:40 PDT
How are you going offline?  Removing the cable, or using the OS to disable the network connection?  Or by selecting the browser menu item "Work offline"?  If the latter, I believe that calls close() on all PeerConnections (connected or not!)  Whether it should (and what errors should be thrown) is a question for discussion.
Comment 3 User image Jason Smith [:jsmith] 2013-04-15 00:56:23 PDT
(In reply to Randell Jesup [:jesup] from comment #2)
> How are you going offline?  Removing the cable, or using the OS to disable
> the network connection?  Or by selecting the browser menu item "Work
> offline"?  If the latter, I believe that calls close() on all
> PeerConnections (connected or not!)  Whether it should (and what errors
> should be thrown) is a question for discussion.

I chose work offline to move to go offline during this test case.
Comment 4 User image Lennart Grahl 2018-04-07 15:52:42 PDT
It definitely doesn't call pc.close() at the moment but it probably should (and then just follow the spec from that on).

Note You need to log in before you can comment on or make changes to this bug.