Bug 160769

(In reply to BikeHelmet from comment #0)
> Expected Results:
> Both versions should recover all previously opened documents.

No, they only should recover *changed* documents (which have something to recover). Previously, LibreOffice confused people by suggesting them to "recover" documents that had no changes (bug 57414). That was fixed in version 24.2 (release notes at [1]).

[1] https://wiki.documentfoundation.org/ReleaseNotes/24.2#Core_/_General

(In reply to Mike Kaganski from comment #1)
> (In reply to BikeHelmet from comment #0)
> > Expected Results:
> > Both versions should recover all previously opened documents.
> 
> No, they only should recover *changed* documents (which have something to
> recover). Previously, LibreOffice confused people by suggesting them to
> "recover" documents that had no changes (bug 57414). That was fixed in
> version 24.2 (release notes at [1]).
> 
> [1] https://wiki.documentfoundation.org/ReleaseNotes/24.2#Core_/_General

This likely should be left to the user, giving them the option to recover all of them or only changed ones. It is very disruptive when LibreOffice crashes with the new behaviour.

Here is a common scenario:
-An office worker is looking at inventory / spreadsheets / reports before a Zoom meeting with higher up management. They are also referencing some new policy documents, so that they can discuss how the changes are going on-the-floor, and have other documents opened from previous discussions with employees/managers. Some resumes are also open, and they are evaluating possible new hires. (Maybe they a half dozen restaurants in a 60km area for a group of owners/shareholders?) In total there are about 30-40 documents open, enough that the recently opened list will not catch them all.

The Zoom meeting starts. Things are going well for a few minutes. Then LibreOffice crashes abruptly. Upon restoring it, it does not reload all of the relevant documents, but only the changed ones. The employee has to scramble to locate and reopen things. The meeting takes almost 30 minutes longer due to having to find everything again. Everyone is annoyed.

I cannot think of a business user that would want the new behaviour. I would make it a choice in the recovery dialog. Microsoft Office uses the old behaviour, which I think most business users and power users would consider correct. Since it was confusing enough to some users to create a bug submission and patch, I suggest expanding the recovery dialog to accommodate both use cases and expected recovery behaviours. You could even collect telemetry data on that, and discover exactly how many people expect each method. I suspect that it's more balanced than you'd assume.

Justin, what are your thoughts? Your bug 57414 comment 22 suggests thought has been put into having a logical behaviour depending on the type of recovery.

Quoting from bug 57414 comment 22:

There are three types of Recovery. One is emergencySave (an exception in the program triggers a save-and-restart), another is SessionSave (when the OS shuts down), and the third is a timed autoRecovery.

In the case of EmergencySave and SessionSave, the intent is to recover the working environment, so ALL documents are attempted to be recovered.

In the most general case (the timed autoRecovery) the patches only try to recover modified documents that have a recovery file.


So, I tend to agree with Mike in comment 1 and the request to specifically do it this way in bug 148438. In response to OP, I'd say that recent documents exists to find those documents easily, so I don't see how re-opening documents manually could be a problem.

In general, it is not a good idea to have lots of documents open, so having LO "recover" the entire last environment would not be smart and encourage bad behaviour. In this case LO itself has no idea why it is restarting, so it is best to just recover modified-but-not-saved files.

Thanks Justin.
Let's close as "Not a bug" then.
BikeHelmet, if you think a different path can be taken to avoid confusion (maybe better text in the dialog?), please feel free to open an enhancement request.

(In reply to Justin L from comment #4)
> Quoting from bug 57414 comment 22:
> 
> There are three types of Recovery. One is emergencySave (an exception in the
> program triggers a save-and-restart), another is SessionSave (when the OS
> shuts down), and the third is a timed autoRecovery.
> 
> In the case of EmergencySave and SessionSave, the intent is to recover the
> working environment, so ALL documents are attempted to be recovered.
> 
> In the most general case (the timed autoRecovery) the patches only try to
> recover modified documents that have a recovery file.
> 
> 
> So, I tend to agree with Mike in comment 1 and the request to specifically
> do it this way in bug 148438. In response to OP, I'd say that recent
> documents exists to find those documents easily, so I don't see how
> re-opening documents manually could be a problem.
> 
> In general, it is not a good idea to have lots of documents open, so having
> LO "recover" the entire last environment would not be smart and encourage
> bad behaviour. In this case LO itself has no idea why it is restarting, so
> it is best to just recover modified-but-not-saved files.

That suggests that there is a bug here? If emergencySave is supposed to recover everything, and after a crash it doesn't, then clearly it crashed in such a way that it did not have a chance to do so, and is depending upon the timed autoRecovery instead? So there's a bug, just not the one from the original post. It still seems like it would be more prudent to give people the choice. An overlapping layer of reliability.

The recent documents list is often not long enough, and organizes based on time originally opened, not which documents were recently used. If your work involves opening and closing a bunch of incoming documents or supplier sheets throughout the day, but not working with them, and instead working within other documents that are left opened longer - then it will not have useful files in the list.

At the end of the day it's your choice as the developers/maintainers, but I would encourage you to think of users that are in the business world and not in the programming or home use world. It may be bad behaviour, but it's exactly how many businesses work, like restaurants.

Another option if this is very unappealing, would be to create a "recently saved" list - as this type of user has no use for recently opened documents, and only cares about the ones that they are saving. The priority is completely opposite to how Justin outlined. Work sheets and supplier pricing updates and whatnot can just be redownloaded/reopened from email, but the documents opened for a long time are actually the priority. Those ones are the ones that are sometimes ignored by auto recovery and the recents list, depending on saving behaviour and how long ago they were originally open.

Just food for thought, but I think they could be good changes to broaden the appeal to different types of users and use cases.

I also thought this was a kind of regression and was going to file it as a bug. 

Before updating to 24.2, I have often left several files opened which need constant attention whether they are worked on or not, and killed soffice.bin process manually in order to restore the status later in the same way as the Internet browser restores previously opened tabs. Still, when it comes to AutoRecovery on Libreoffice, I know it is not an expected behavior, so I understand that this is not a bug, rather a function which should be implemented directly or via an extension.

(In reply to snail from comment #7)
> rather a function which should be implemented directly
That is bug 146769 (Reopen documents from previous session on start).

Yes, I agree with others, I too have long used/expected (and welcomed) the behavior of it opening not only files with unsaved changes, but also files I work on perpetually or at least extended periods for customer engagements.  I as well was ready to file a bug (sort of did, but for other kde framework problems), but was steered here as a separate thing.

I can see both sides of the coin, but this "fix" was certainly unexpected and unwelcome behavior for me as a bug/not bug. If nothing else, I would ask for an option to restore only unsaved files, or restore all open files.

I think solutions like bug 146769 and bug 117237 should be prioritised, instead of some users relying on killing the process to restore all documents.

But considering some users are surprised by the new behaviour, I'm wondering if the dialog could somehow show all files, but differentiate between modified and unmodified ones, like two sections with "Needs recovering" and "Changes already saved" headers, still giving the options to restore unmodified. That would make it clear what might have missing data, and what definitely wouldn't.
Just a thought.

(In reply to Stéphane Guillou (stragu) from comment #10)
> I think solutions like bug 146769 and bug 117237 should be prioritised,
> instead of some users relying on killing the process to restore all
> documents.
> 
> But considering some users are surprised by the new behaviour, I'm wondering
> if the dialog could somehow show all files, but differentiate between
> modified and unmodified ones, like two sections with "Needs recovering" and
> "Changes already saved" headers, still giving the options to restore
> unmodified. That would make it clear what might have missing data, and what
> definitely wouldn't.
> Just a thought.

There's no need to reinvent the wheel here. Standard behaviour in Windows is to stick a * in front of the filename if it needs saving. Although not universal, I have seen that in Linux Distros and MacOS as well. You can use the same dialog window, with all files present, and just stick a * on the ones with unsaved changes. If the list is sorted alphabetically, that should also put them straight at the top.

Then put two buttons below: [Recover All Documents] [Recover Only Unsaved Documents] to determine the recovery behaviour that the user gets.

And then put in a new confirmation when exiting LibreOffice from the File menu specifically (not the X in the top right), similar to the Opera Web Browser.
"Reopen all documents at next start?" [Yes] [No] [Cancel]

(Not the wording of Opera's, but you get the idea once you've tried it once or twice.)


And then as a final quality of life update (This would require larger code changes), have it backup the open documents (on exiting) to the working drive so that even if the originals disappear, it can fully recover everything at the next start - both modified and unmodified - if desired. This should be toggleable in the Settings in the Load/Save area. Likely beside the "Always create a backup copy" option, which saves backups onto the working drive when saving. I would split that to two options if implemented, "Always create a backup copy when saving", and "Always create a backup when exiting LibreOffice"

If this is implemented, it should alert you if the original for reopened documents is no longer present. The type of person using this feature regularly would want to know if suddenly their original has been renamed/deleted/etc from outside of the program. So this adds a lot of polish on top, for that type of user, in that you are treating their precious documents as extra important. By slightly modifying the recovery feature you effectively add a full secondary backup layer to LibreOffice - unless they shut it off. At least a few people would heap praise on the programmers if implemented right. The wording that I would use (on a bright banner bar at the top of the open document) would be: "This document was not found at the previous filename and location. Please re-save this or reopen the original if necessary."

That alerts the user to go re-open it if it changed from (for example) "2024-03 Quarterly Inventory.ods" to "2024 Q1 Quarterly Inventory.ods", etc.; they either go open the proper one and save to it, or re-save the open one and continue on from there. It avoids them accidentally splitting their document into two chains when they (or someone else) were doing folder/filename cleanup.

That's about all the gotchas that I can think of. With that implemented, it becomes an incredibly handy feature for one type of user. Even with only a limited / first part implementation, it's much more useful than what we have now. I hope that helps a programmer that doesn't need this at all, to understand a feature implementation that would be very useful to some other types of users.