Losing work

[edemaine]

On bad Internet connections, Stop Editing occasionally loses work, presumably when the shareJS editor has lost connectivity, but the document gets closed anyway. [Justin]

• [x] Stop Editing shouldn't close when in disconnected state
• [x] Perhaps should similarly warn on closing browser window, in case someone doesn't notice the "Saving changes..." message.
• [ ] Can we detect whether ShareJS has sent all changes, even if we haven't gotten a matching document from the Mongo subscription? If so, this would work a lot better when multiple people are editing and one tries to stop. It looks like the nothing pending event / hasPending method might do this.
• [ ] Disconnected state should have visual feedback to the user

I am also worried about editors that get lost because of a server restart. Perhaps we should switch ShareJS to use persistent state, so that we can recover after server restart? This would require care in resuming callbacks. Alternatively:

• [x] Client should refuse to auto reload on server restart (via Reload.onMigrate) when it has an editor with unsaved changes, and instead tell the user to copy it to another place and then manually reload. [Yevhenii]

[edemaine]

More generally, I think there's a race between Stop Editing triggering an update and destruction of the shareJS editor and propagation of the shareJS updates. [Jeffrey reported this.]

A simple fix would be, on the client side, for the Stop Editing button to wait for #152 to report "all changes saved" before actually calling messageEditStop.

[edemaine]

The simple fix is now done, with clear user feedback (disabled "Stop Editing" button, and status bar change). Disconnected state would still be nice to detect / report, but at least there's no more race and loss of work with good network connections.

[edemaine]

I just pushed a change to prevent lost work when closing/reloading the tab prematurely, or when the server pushes a reload. In the latter case, the user gets a message to save their work elsewhere before reloading.

This issue raised its head again when Coauthor was behaving very slowly, so a lot of work got lost when restarting the server (to try to fix the performance problems).

Edit: I didn't get this quite right; four hours later, 211f132 should really fix this.