Description: If you have a document open, you have done some edits, and then switch to other apps for a while, and those apps require lots of system resources, the system will (hopefully) notify the Collabora Office app that it will be terminated (and after that terminate it with an uncatchable signal). This invokes the applicationWillTerminate: method of the UIApplicationDelegate. That will (now, after fixing tdf#126974) just cause the app to exit. What it *should* do is probably cause the current open document, if any, to be saved in an orderly fashion, and only then exit. On the other hand, as the app has a separate "Save" button, and a "File > Save" menu entry, perhaps the intended workflow is not one where the document is saved automatically, but only on user request? On the other hand, the app does auto-save changes to the document at regular intervals already, if I understand correctly, so doing an auto-save right before the system decides to kill the app would not be that different. (Actually, this is IMHO self-contradictory. The old-fashioned desktop editor paradigm where an open document is saved only when explicitly requested is mixed with a more modern paradigm where the document being edited is automatically saved, ideally constantly (for which our time-based auto-save is a substitute), and no explicit saving necessary of even offered. The app has both automatic saving *and* explicit saving...) Steps to Reproduce: . Actual Results: . Expected Results: . Reproducible: Always User Profile Reset: No Additional Info: .
Nicolas, what do you think?
(Note that doing something in applicationWillTerminate: is not 100% safe, though; I read that there are situations where the system will kill the app right away with SIGKILL without causing that method to be called first.)
I often run into out-of-memory situations on my Android phone and think it's quite a common situation on phones/tablets. I therefore suspect, that saving the document when the app gets stopped/killed by the system is the right thing to do. Maybe we could even get rid of the "save" button/menu entry and do the following things: * do an explicit save when using the back button "<" * auto save every 30s (or what ever it is at the moment) * save when the app gets stopped/killed by the user or system (kill the app) Pages on iOS doesn't have a save button as far as I can tell. MS Word on iOS does "Auto save" per default and the user can change it to manual save.
Do you think it is possible currently that some user might think/act like this: "Oh, so there is an explicit save button, and File > Save, that means the document is not saved unless I tell it too. Good, then I can do some radical change just to check something, I won't save it... [proceeds to destroy most of their document] [document gets auto-saved] [switches to another app] [Collabora Office app is killed by system] [starts it again and opens the document] [notices the disaster] But I didn't save it!!! [runs away screaming]" (That is after all how I often work in desktop LO, and old-fashioned editors. I know that nothing is saved unless I want, so I can experiment freely.) --tml
Hard to say if this scenario happens. But I believe, that explicit and implicit saving is not an ideal mix (however I'm by far not a UX/UI expert). Looking at how tools in the Apple space tend to work I come to the conclusion, that user should not need to save manually. This is also documented here: https://developer.apple.com/design/human-interface-guidelines/ios/user-interaction/file-handling/ "In general, don’t make people explicitly save files. Instead, save changes automatically at regular intervals, when opening and closing files, and when switching to another app." If it's not a huge effort I think we could also follow this pattern and remove the explicit save button / menu entry. Of course this "auto save strategy" will not allow the scenario you mentioned anymore. But people will probably learn (maybe the hard way) quite fast, that they need to make a copy first if they want to experiment freely. Does this help?
Yes, thanks, that matches my own thoughts.
Moving to NEW as agreed in the ESC meeting
Dear Tor Lillqvist, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Ideally this would trigger an AutoRecovery SessionSave. (AFAICS, this is only triggered by some legacy X11 code - perhaps in VCL=gen.) Various bug reports request similar responses for GTK/KDE/Windows. I think Tor's comment 4 is accurate. LO has all the plumbing to do an ODF recovery save in the user's backup folder, and restore on app-start. So that just needs to be wired into the applicationWillTerminate.