Description: LibreOffice document recovery (DR for short) breaks UX principles as described in https://wiki.documentfoundation.org/Design/Principles : 0) DR pops up at unexpected times (ux-consistency?): After years of using LO I couldn't really figure out when DR is triggered, but it regularly comes up when I don't remember having anything that would worth saving (typically I use LO for quick preview before switching to MS Office). 1) DR doesn't let me work (ux-interruption): The document I want to open doesn't come up until I deal with the DR window, even though I try to work with a completely different document. This is probably the most annoying component. 2) Confusing wording (ux-affordance?): The action buttons on the first DR screen are called "Start" and "Discard". Since the window appears during the startup of the application, this is confusing, because "Start" can be interpreted as continuing starting the application while "Discard" can be interpreted as discarding this annoying window, while the buttons have opposite effects. 3a) It takes two confirmations to get over DR (ux-interruption, ux-visual-hierarchy): I know this should be a safety tradeoff, but it's *really* annoying to click through not one but to modal dialogs to get to my document unrelated to DR. It's also not visually easy to tell which button will result in discarding the document/continuing execution (that can either be desired or dangerous, so simple red/green coloring wouldn't do I guess). 3b) It takes a confirmation to see recovery result (ux-interruption, ux-minimalism): Let's say I really did want to recover something. What is the purpose of making me click Finish in order to my nervously awaited recovery result can be displayed? Steps to Reproduce: 1. Save a document 2. Add some content to the document without saving 3. Kill LO 4. Open LO providing a different file (document2) in the command line to trigger DR Actual Results: DR shows up, preventing work on document2. Expected Results: I want to be able to work with document2 without blocking modals. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.3.5.2 / LibreOffice Community Build ID: 184fe81b8c8c30d8b5082578aee2fed2ea847c01 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
So basically what you want is that LibreOffice only shows the DR dialog when you try to open the a file that had previously crashed? If you try to open some other file (even if a previous LO session crashed), you want the DR dialog to not be shown? AFAIK the recovery info is obtained from the hidden backup file that is created while the document is open. So I guess this might be possible, but I'm not an expert on the inner-workings of file recovery. Maybe we could have the following workflows: 1) If LO crashes and the user tries to open a file that has backup information, then only the DR dialog is shown (as is today) 2) If LO crashes and the user tries to open some other file, the file is opened and becomes ready for editing; and at the same time the DR dialog is shown to indicate that there are files pending recovery. Let's hear from the UX team.
(In reply to i_dont_want_to_recover from comment #0) > 0) ... (typically I use LO for quick preview before switching to MS Office). Uh :-) (In reply to Rafael Lima from comment #1) > So basically what you want is that LibreOffice only shows the DR dialog when > you try to open the a file that had previously crashed? => NEEDINFO The dialog has been revamped recently for bug 114508 and should be more accessible now. Given the DR pops-up when needed, I guess the other inconveniences (interruption of workflow, confirmation steps) are acceptable.
> So basically what you want is that LibreOffice only shows the DR dialog when > you try to open the a file that had previously crashed? My preferred solution would be an implementation that doesn't block startup/display of the requested document. I guess that getting notified ASAP about potentially corrupt documents is a good thing, because the user can take actions early, before the error becomes unrecoverable or cascades for some reason. It seems reasonable to block editing if a file with recovery info is opened until DR is decided, but being able to read the last saved version should be possible without the decision. Also, I brought up 0) because part of the problem seems to be that in my experience sometimes LO thinks it crashed when in fact it didn't. As I said, I usually only touch documents in MS Office, yet I'm still regularly faced with DR, although there shouldn't have been any modifications and I exit LO clean. (This would deserve a separate bug, but as it's non-deterministic, I can't give much details unfortunately :( ). This means that in some cases I want to work on the same document without being interrupted by DR, because I know there is no need for recovery.
[Automated Action] NeedInfo-To-Unconfirmed
The topic was on the agenda of the design meeting but didn't receive further opinions. Point is that we should aim for no crashes at all. To my knowledge, the dialog comes up if some lock file is present. And respectively you create this file with the first editing of a document. I mean, while in IT all is possible, the balance to effort is not given here. Furthermore, I cannot confirm that the DR dialog shows up with unexpected timing - besides you start LibreOffice ages after it crashed. But leaving the ticket open for QA to verify. My take is to resolve the request as WF.
> Point is that we should aim for no crashes at all. Well, good luck with that :) > Furthermore, I cannot confirm that the DR dialog shows up with unexpected timing Unexpected timing is just a circumstance in my specific case, the ticket is not about detecting recovery situations, but responding in a user-friendly way when recovery seems necessary (false detection or not). > I mean, while in IT all is possible, the balance to effort is not given here. Again, this ticket is not about unexpected recovery situations. IMO the current UX wastes the collective time of users, that is worth improving. I also referenced how the current behavior goes against the project's own UX principles, which was not argued. On the other side, I don't see how the effort is estimated here, as I don't see any concrete proposal for resolution.
(In reply to i_dont_want_to_recover from comment #6) > On the other side, I don't see how the > effort is estimated here, as I don't see any concrete proposal for > resolution. You suggested yourself to start the application and show an infobar telling the user "LibreOffice has crashed lately. You may recover the latest state. [Recover]" and the dialog starts on click. What I suspect is that recovery information are overwritten if, for example, the application crashes because of a template that is loaded on start-up. It's a risky situation and the value of data integrity is higher than being interrupted. But this decision is up to the developers.
> You suggested yourself to start the application and show an infobar telling the user "LibreOffice has crashed lately. You may recover the latest state. [Recover]" and the dialog starts on click. I don't remember being this specific, but I'd like this approach :) > It's a risky situation and the value of data integrity is higher than being interrupted. So far the risk of recovery data corruption wasn't stated as a fact (you wrote you "suspect" there is a risk). If there is such risk, I agree that the UX should not take priority (but maybe the recovery process should be improved?).
This is actually more of a meta-bug; and, specifically, it contains a request for what I've just filed as bug 155257. I am also of the opinion that some consolidated thinking should happen on what the UI/UX of document recovery should be. I believe it should not be difficult to resolve half the bugs blocking "Document Recovery" with not a lot of work on the dialog and its behavior.
I understand your bug 155257 as a duplicate of this request.
(In reply to i_dont_want_to_recover from comment #0) > 3b) It takes a confirmation to see recovery result (ux-interruption, > ux-minimalism): Let's say I really did want to recover something. What is > the purpose of making me click Finish in order to my nervously awaited > recovery result can be displayed? That part was fixed by Justin Luth for 24.2: https://git.libreoffice.org/core/commit/6444f5e2c5c8b3d1fac12755af09339083c74055 tdf#145606 autorecover: skip "Finish" button if all recovered OK.
(In reply to Heiko Tietze from comment #7) > What I suspect is that recovery information are overwritten Indeed. One RecoveryList is shared with EmergencySave, SessionSave, and timed AutoRecovery. By default it would be lost within 10 minutes of opening LO. In general, I don't see a big problem with the current recovery workflow. It shows up when there has been a likely data-loss situation unless the user intervenes, so having it start at the beginning and be "intrusive" is very appropriate. 24.2 has seen significant changes to this code. I suggest closing this bug report, heavily testing 24.2, and filing reproducible bug reports about any clearly wrong results.
(In reply to Justin L from comment #12) > 24.2 has seen significant changes to this code. I suggest closing this bug > report, heavily testing 24.2, and filing reproducible bug reports about any > clearly wrong results. I agree with Justin here, let's close this and open new tickets (one per issue please, so it stays focused and actionable) if problems remain in 24.2, without duplicating what already exists in meta bug 112970 and bug 77999. Thank you all!