pads silently disconnect when browser suspends a background tab

[ryanpitts]

My team uses etherpad-lite for a lot of internal planning work and to document open community meetings, so we often have multiple pads open in different tabs for extended periods of time. Many times when a pad loses connection (because someone shut their laptop and their machine went to sleep, or because the browser offloads tabs that have been in the background for a while), the pad will show a "disconnected" prompt. But not always.

We regularly experience silent disconnections—if you happen to notice and reload, the pad reconnects just fine. But if you return to a tab and don't notice that it disconnected, changes that you make aren't stored and it's easy to lose a lot of work. We're totally aware of why a socket might lose connection, but it's unclear why sometimes there's a warning and sometimes there's not.

Is this a known issue? Are we strange in the way we use etherpads? I feel a little awkward about filing this as a bug, but I did a ton of searching and I can't find much description of this problem anywhere.

[JohnMcLear]

No, you are using Etherpad right and this is not a known issue. You should have a disconnected msg and an overlay. Can you provide some exact steps to replicate?

Thanks for letting us know.

This is the connection status logic: https://github.com/ether/etherpad-lite/blob/develop/src/static/js/pad_connectionstatus.js

And the auto reconnect logic: https://github.com/ether/etherpad-lite/blob/develop/src/static/js/pad_automatic_reconnect.js

[joassouza]

We had the some problem with a user with unstable internet connection. This bug is quite difficult to replicate and really serious. We've tried to simulate an unstable connection without success.
We are using Etherpad 1.7.5

[JohnMcLear]

Looking into this now.

[JohnMcLear]

Wait.. In settings.json

  /*
   * Time (in seconds) to automatically reconnect pad when a "Force reconnect"
   * message is shown to user.
   *
   * Set to 0 to disable automatic reconnection.
   */
  "automaticReconnectionTimeout": 0,

This is the default, what's the logic here? Surely that's not a good default setting?! :D cc @muxator any idea what the deal is here?

My method for initial testing is..

1. connect to pad. Type stuff.
2. minimize browser.
3. killall node (makes server disappear)
4. wait a few mins (I'd love to know what the timeout is here)
5. tab back to browser, see if I have any msg.

What I expected would happen,.

1. Disconnected msg would be visible.

What does happen.

1. Disconnected msg is visible.

Another approach..

1. connect to pad. Type stuff.
2. minimize browser.
3. put laptop to sleep
4. wake laptop up from sleep
5. tab back to browser, see if I have any msg.

What I expect to happen:
Go back to browser, see if it will reconnect

What happens:
Try to type and it disconnects user!

Next I'm going to test waiting longer for reconnect..

[luixxiul]

  "automaticReconnectionTimeout": 0,

It was introduced here: 009cd31#diff-8ab11a170627f11a32a1d642d7114743R126

[JohnMcLear]

Good news. I can replicate.

1. connect to pad. Type stuff.
2. minimize browser. (probably not required)
3. put laptop to sleep
4. wake laptop up from sleep
5. tab back to browser, see if I have any msg.

What I expect to happen:
Go back to browser, see if it will reconnect after x seconds.

What happens:
It claims to be reconnected but typing anything sends bad changeset.

https://www.youtube.com/watch?v=COyju-u9Sek

I think I might be able to reduce test down to just making network disappear using network tools.

[JohnMcLear]

  "automaticReconnectionTimeout": 0,

It was introduced here: 009cd31#diff-8ab11a170627f11a32a1d642d7114743R126

Okay thanks and note that @lpagliari is on other projects now so wont be able to fix this. I don't think she "caused" the bug but I find that setting just weird.. It feels like it should be on by default...

[luixxiul]

I don't think she "caused" the bug but I find that setting just weird.

Me too, no offense really :-)

[ryanpitts]

omg, I'm so sorry, I had this thread open in a tab and a reply typed out and never hit submit!

Quite difficult to replicate is my experience too. I know this kind of sounds ridiculous, but the closest I can get has been something like:

1. open an etherpad in a tab
2. leaving etherpad as active tab, close my laptop lid and wait a few seconds for machine to fall asleep and lose network connection
3. open laptop and revisit tab with etherpad

I generally see the "reconnecting" message in that tab, and sometimes it does, in fact, reestablish connection. But not always, even though the "reconnecting" message disappears. When that happens, there's no visual hint that what you're typing isn't being saved.

A couple things I've wondered about:

• if my laptop takes a little too long to reestablish a network connection, is it possible that etherpad gives up trying to reconnect to the server in the meantime
• I'm not sure but I feel like clicking in the etherpad might dismiss the "reconnecting" message ... maybe that cancels it? Or at least dismisses so you'd never see a followup error message

So, maybe my attempt at replicating wasn't as ridiculous as I thought! I'm so glad we aren't the only ones who've seen this. Thank you so much for looking into it.

[JohnMcLear]

Sorry I have kids dumped back on me. I have to jump off this now.

[JohnMcLear]

one hand hax.

1. connect to pad
2. use clumsy to drop all packets
3. type smt
4. dsiable clumsy
5. after reconnwct tryu type agaiun
   chanfset errpr

[JohnMcLear]

https://youtu.be/VFBcKDDpTd8

[JohnMcLear]

Okay cool I have a patch in that solves a huge chunk of the problem.

• Doesn't allow edits during reconnecting state.
• Gets proper rev # of doc prior to submitting next Changeset.

If I can't solve item #2 I can always use the internal reload method to load the pad back into the page.

This should land tonight, dinner time now.