-
Notifications
You must be signed in to change notification settings - Fork 115
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
Warn if document is not saved when closing - Data loss #3373
Comments
Did you encounter any data loss? Would be good to check the Collabora logs then. In general this should not be a problem with Collabora as the file state is always managed on the server so even if the browser window is killed the changes are persisted on the server. |
yes, a filled document was empty.
in this case not and It would be nice to popup a message: not saved |
In that case it would be interesting to see any logged errors still. Even if the failure occurs once the document should still be on the Collabora server and available to open again with the content i think. |
FYI @pedropintosilva as the autosaving and a possible manual save blocking dialog is probably something more on the online side, though I'd rather prefer to fix the root cause instead of having a blocking operation that could still lead to failures on saving. |
Thanks @internethering for testing and taking the time to report. This is very valuable. Yes I agree @juliushaertl . @internethering are you able to gather those logs? |
@internethering, thanks for your report.
The document is always automatically saved upon closing/unloading the document. Of course there is no expectation that the user must be there and invoke the save command for the server to save; this is done automatically, in the background. If, for whatever reason, saving and uploading to storage cannot be accomplished, error logs will clearly indicate data-loss. As a last-resort, there is a feature to quarantine documents that aren't uploaded to storage. This needs enabling from the config, and the files are only accessible by an admin on the server, but the feature is there as a last resort. Indeed, if you open a text document, make a change and close the browser without saving, the document should still be saved and no data loss should occur.
The pop-up message will not be very helpful, I'm afraid. For one, because the user can close the browser and we cannot stop them. It would be very interesting to have steps to reproduce, if indeed you have found a reproducible data-loss case. Similarly, would be very helpful to get trace-level logs from coolwsd, to see exactly what is happening. Thank you. |
Hmmm. I'm having trouble with not saving unless manually saving, too. Will see if I can reproduce reliably. |
What's odd is that if I open the document in a 2nd user on a 2nd browser at step 2, then on step 3 I get the collaborative experience; each user can see what the other writes. Yet when it's closed - without saving - data seems lost. nextcloud-bug.webmI will look for any logs. |
Yes, this is definitely something that should not happen. The Collabora server logs would be very helpful in that case. |
There's nothing in the nextcloud logs. Some stuff about can't find a I'm using "CODE" - where would I find the server logs for that? |
By version of Online, that should not be CODE but Built-in CODE Server and that issue is CollaboraOnline/richdocumentscode#238. |
Could this not be related to #238? |
Closing this as it looks like CollaboraOnline/richdocumentscode#271 which is also closed |
Describe the bug
If, for whatever reason, the document is not saved automatically when editing, the modified content is irrevocably lost after closing the tab or document.
Expected behavior
If the document has not yet been saved, a pop-up message should warn you when closing that it still needs to be saved.
Client details:
Server details
Operating system: Gentoo Linux
Web server: Apache 2.4.57
Database: MariaDB 10.11.5
PHP version: 8.1.26
Nextcloud version: 28.0.1
Version of the richdocuments app 8.3.0
Version of Collabora Online 23.5.604
The text was updated successfully, but these errors were encountered: