-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pads silently disconnect when browser suspends a background tab #3830
Comments
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 |
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. |
Looking into this now. |
Wait.. In settings.json
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..
What I expected would happen,.
What does happen.
Another approach..
What I expect to happen: What happens: Next I'm going to test waiting longer for reconnect.. |
It was introduced here: 009cd31#diff-8ab11a170627f11a32a1d642d7114743R126 |
Good news. I can replicate.
What I expect to happen: What happens: 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. |
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... |
Me too, no offense really :-) |
omg, I'm so sorry, I had this thread open in a tab and a reply typed out and never hit submit!
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. |
Sorry I have kids dumped back on me. I have to jump off this now. |
one hand hax.
|
Okay cool I have a patch in that solves a huge chunk of the problem.
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. |
Okay I only have time for a temp fix that reloads the pad upon reconnect, it's not ideal but it works. It's possible it doesn't fire on stale. I tested disconnect states, unreliable states, sleep / awake states and it seems to behave appropriately. It is a vastly better UX that what's currently in develop but really the pad contents should reload without an entire page refresh. At least an entire page refresh in Etherpad is cheap but still, it's hacky. |
This is just fantastic, thank you!!
Seriously, just that change right there will eliminate so much heartache. (Well, "so much" is maybe overselling it because the silent disconnect issue feels relatively rare. But when you lose a bunch of work because you thought you were connected, it does feel pretty bad.) |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
would sure love to see this one land! |
See above the fix was merged. |
Oh great, thank you! Looking forward to 1.8.5! |
@ryanpitts @joassouza We recently made some changes to improve handling of reconnects (see #4331). Please keep an eye out for regressions when you upgrade. |
Thanks! I saw that 1.8.6 landed, and I'm planning to upgrade either this week or next. |
@ryanpitts: The change that I'm referring to is not in v1.8.6; it will appear in the next release. A heads up: There are a couple of bugs in v1.8.6 related to sessions. If you use the HTTP API then you will probably need to cherry-pick 3886e95 and 4332aff (or just check out the |
This one popped up again, and seems pretty critical. Using AUTOMATIC_RECONNECT_TIMEOUT only seems to work if that tab has continous focus. Recreate steps:
Version |
I discovered an error in the handling. During testing there was a ping timeout. I am now reconnecting the socket io connection if this is the case. |
Until recently I was using an old 1.8.17 and I never had this issue with it. Sometimes of course the connection went down but I had the popup message clearly visible so I knew I had to reload the tab. But I've just upgraded my instance to 2.0.3 and although everything else works as expected, I encounter this faulty behavior several times a week now. I have 2 machines with at least one pad always open on Chromium and sometimes, after leaving the tab open for hours in the background without typing anything, if I get back to it I can still write, no popup appears, but actually the connection went down and reloading the tab reveals that the latest words/lines have not been saved. I'm using the Docker version, with a properly set up Nginx as SSL-offloader. I did not change the configuration that was working with Etherpad 1.8. |
Thanks for the answer. If the pad disconnects silently from the socket. Can you check the development console of your browser. I added a message when this occurs because we don't really have a reason until now. It should say something like Reason for disconnect is XY. |
There's never a popup or reconnect of any kind, and the console only shows these messages:
|
edit: ignore my last comment about nginx misconfiguration. The issue is still 100% there. |
I searched this codebase, and nowhere does it have document.hasFocus(), or even window.onfocus . Has etherpad never handled tab switches or window focus events correctly? |
2.1.1 fixes this issue. It now reconnects like in v1 properly |
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.
The text was updated successfully, but these errors were encountered: