Offline Handling

[svenefftinge]

Users shall be notified when the connection to the backend got lost. Since the possibilities to work offline are very limited (some editing in already opened editors but without any additional services).

I propose to have a modal overlay (similar to the one we have for dialogs), that tells the user about the offline state. It should go away when the backend can be reached again.

[hexa00]

And what would be the criteria for losing the connection ?
that the connection is closed ?

I'd like to avoid that you get this popup often and can't work properly on let's say a not so good wifi connection..

[svenefftinge]

I'd like to avoid that you get this popup often and can't work properly on let's say a not so good wifi connection..

Yes, for sure that must be avoided.
Akos was proposing to have a dedicated GET /alive service on the backend that we poll.

[hexa00]

I think this may not be enough ?

Let's say:

User is typing...
Connection is lost...
User keeps typing...
GET /alive is done...
Timeouts after 1-2 secs ?

Then the user will have typed 1-2 secs in void ?
And on re-connection he will have lost the data ?

[hexa00]

Feels like what we would need is something that sends keystrokes in the editor to the service and the services confirms these as received.

And have a buffer of unconfirmed data... if the unconfirmed data gets too big we pop the connection lost dialog and then on reconnect we can send back that unconfirmed data.

[hexa00]

For other services it could be that if a json-rpc command times out... we issue the dialog.

[svenefftinge]

The user will only loose what she typed, if the backend is never going online again.
Even if that happens loosing what was typed within even 20 seconds would not be super dramatic.
Please keep in mind, that it is a worse case scenario.

[hexa00]

@svenefftinge personally I don't like the idea that I could lose 20 secs...

I would much rather have something like mosh

And I'm not so sure how worst case it is... it heavily depends on that GET alive request...

Is the idea I propose problematic to implement ? Or there's another issue with it?

[marcdumais-work]

We had reports from internal users that some strange things happen when editing go files (our most popular language extension ATM, the problems are not necessarily specific to go, as far as we know) .

We do not know the root causes of these reported problems, but suspect that they may have to do with network issues (short disconnections):

theia-ide/theia-go-extension#10
#1169

If they are caused by disconnections, they might fit in this issue? i.e. gracefully handle disconnections/re connections.

[hexa00]

Btw also something to think about with this issue is what happens when you have autosave off.

[svenefftinge]

@marcdumais-work Thanks for sharing that feedback from your internal users. We should investigate if that is still happening. It doesn't sound like it is related to offline handling, though.

[svenefftinge]

In the dev-meeting, we agreed on going with a simple solution fro now, that

• lays over a modal layer, telling the user she is offline.
• based on a simple GET request
• the timeout needs to be finetunes, not to get on the nerves (not false positives with spotty connections)

Anton said he wouldn't like the modal, mode but would prefer non-modal indication (e.g. coloring the status bar red). We agreed that we will first try the modal and if the experience is not good we do another round.