Bug 114508 - Confusing dialog about discarding recovery data can lead to data loss
Summary: Confusing dialog about discarding recovery data can lead to data loss
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
5.4.2.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: difficultyMedium, easyHack, skillCpp, topicUI
: 112188 115564 116560 (view as bug list)
Depends on:
Blocks: Dialog-Msgbox Document-Recovery
  Show dependency treegraph
 
Reported: 2017-12-17 09:19 UTC by Dan Dascalescu
Modified: 2021-05-01 09:55 UTC (History)
15 users (show)

See Also:
Crash report or crash signature:


Attachments
Recovery dialog with two Calc documents (25.12 KB, image/png)
2017-12-27 10:51 UTC, Heiko Tietze
Details
Mockup for an improved dialog (35.30 KB, image/png)
2018-01-10 20:46 UTC, Heiko Tietze
Details
screenshot (322.80 KB, image/png)
2020-10-19 13:52 UTC, Daniel
Details
recoverydialog (73.84 KB, image/png)
2020-10-20 09:24 UTC, Daniel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dan Dascalescu 2017-12-17 09:19:12 UTC
Description:
My Ubuntu ran out of battery and LibreCalc crashed with three spreadsheets open. When I restarted it, it asked about recovery information. I clicked one of the sheets and then Discard.

What happened is that Calc discarded the recovery info for ALL the sheets, losing me day's worth of data.

Steps to Reproduce:
1. Open 2+ spreadsheets
2. Crash Calc
3. Restart Calc
4. In the recovery dialog, click a spreadsheet you don't care about, then Discard

Actual Results:  
All recovery information is discarded

Expected Results:
Only the recovery information of the clicked item is discarded.


Reproducible: Always


User Profile Reset: No



Additional Info:
Maybe my expectation was wrong, but this can happen to other users. My suggestion would be to disallow selecting any of the spreadsheets in the list, or make the Discard button act only on the selected items.


User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.108 Safari/537.36
Comment 1 Heiko Tietze 2017-12-27 10:51:10 UTC
Created attachment 138679 [details]
Recovery dialog with two Calc documents

Just for clarification, you are talking about this dialog and expect Discard to affect the selected items, somehow?
Comment 2 Jean-Baptiste Faure 2017-12-30 18:18:41 UTC
From comment #1 set status to NEEDINFO, please set it back to UNCONFIRMED once requested informations are provided.

Best regards. JBF
Comment 3 csongor 2018-01-03 06:37:45 UTC
I would like to have the following buttons:
- Discard Selected
- Discard All
- Recover Selected
- Recover All

If the user presses the Discard Selected or the Recover Selected button then the selected document should disappear from the list (and be opened in the background when recovered). 

If the user presses Discard All then the recovery window should be closed and a new empty document should appear.

If the user presses Recover All then the recovery window should be closed and all the recovered documents should appear in separate windows.

Both of the Revover... buttons should ask a confirmation before it actually discards them. 

These buttons would make the process totally clear for the user.
Comment 4 Heiko Tietze 2018-01-03 08:23:28 UTC
(In reply to csongor from comment #3)
> I would like to have the following buttons:
> - Discard Selected
> - Discard All
> - Recover Selected
> - Recover All

That makes the UI unnecessary difficult - and presumes that we have a selection mechanism. IMHO we have two options, a) keep everything as it is or b) introduce checkboxes, check all by default, and provide the functions Recover Selected (which is actually Okay) and Discard All (meaning Cancel). There is no need for a confirmation neither to have various interactions.
Comment 5 Dan Dascalescu 2018-01-03 10:21:33 UTC
Comment on attachment 138679 [details]
Recovery dialog with two Calc documents

@Heiko's attachment: yes, I expect Discard to discard only the selected item, because it's selected.

A quick fix to the confusion would be to disable selection.

Another one would be to rename "Discard" to "Discard all" if more than one document was recovered.
Comment 6 Telesto 2018-01-03 10:52:15 UTC
(In reply to Dan Dascalescu from comment #5)
> Comment on attachment 138679 [details]
> Recovery dialog with two Calc documents
> 
> @Heiko's attachment: yes, I expect Discard to discard only the selected
> item, because it's selected.
> 
> A quick fix to the confusion would be to disable selection.
> 
> Another one would be to rename "Discard" to "Discard all" if more than one
> document was recovered.

Seems the simplest solution, to me. If there a change for the button labels, please consider a change for 'Start' to something more self-explaining too, like "Recover documents" or " Recover all".  

I can think of one situation where individual recovery could be useful, but it's a corner case. For example when a document file generates a crash loop on opening after recovery, which makes it impossible to recovery the other files. But that is more about the the way how the recovery process is implemented, and less about the dialog itself (and I'm not sure about the likelihood to create a situation like that)
Comment 7 Cor Nouws 2018-01-10 13:03:20 UTC Comment hidden (obsolete)
Comment 8 Cor Nouws 2018-01-10 13:05:55 UTC
(In reply to Telesto from comment #6)
> (In reply to Dan Dascalescu from comment #5)

> > A quick fix to the confusion would be to disable selection.
> > 
> > Another one would be to rename "Discard" to "Discard all" if more than one
> > document was recovered.

These quick fixes hide the better solution, because:

> I can think of one situation where individual recovery could be useful, but
> it's a corner case. For example when a document file generates a crash loop
> on opening after recovery, which makes it impossible to recovery the other
> files. 

this is not a corner case for me, but more a need in real life.
Comment 9 Thomas Lendo 2018-01-10 20:27:09 UTC
(In reply to Heiko Tietze from comment #4)
> That makes the UI unnecessary difficult - and presumes that we have a
> selection mechanism. IMHO we have two options, a) keep everything as it is
> or b) introduce checkboxes, check all by default, and provide the functions
> Recover Selected (which is actually Okay) and Discard All (meaning Cancel).
> There is no need for a confirmation neither to have various interactions.
+1 for Heikos suggestions. I like b) as enhancement.

All other ideas are a UX mess. Most people don't know the concept of selecting something by multiple mouse clicks without strong visual response (e.g. a checkbox). Then people will be surprised when files are not recovered because they've accidentally clicked with mouse or tab at one file in the list.

PS: What information is requested with the needinfo state?
Comment 10 Heiko Tietze 2018-01-10 20:46:25 UTC
Created attachment 139033 [details]
Mockup for an improved dialog

All checkboxes are set on by default, which makes the dialog equal to the current workflow. But unlike today the user can unselect one or all files and start the 'Recover selected' operation.
Comment 11 Heiko Tietze 2018-01-10 20:47:23 UTC Comment hidden (no-value)
Comment 12 Telesto 2018-01-10 21:54:34 UTC
(In reply to Cor Nouws from comment #8)
> > I can think of one situation where individual recovery could be useful, but
> > it's a corner case. For example when a document file generates a crash loop
> > on opening after recovery, which makes it impossible to recovery the other
> > files. 
> 
> this is not a corner case for me, but more a need in real life.

Small follow-up. The ability to choose the files to recover might be not enough. (a) Most people will choose recover all, I guess.. (b) And not everybody is able to 'pick' the crashing file, I suppose..

I also would prefer some differentiation between 'recovery' and opening part of the recovery process. The recovery mostly works (as far as my experience goes), but issues while arise at the file opening.. 
The recovery dialog opens again after a second crash. The repairing will start again when pressing Start/recovery, a process which feels very uncomfortable to me, because it's repairing a file which was repaired before a few seconds ago (with some risk failing the second time, call me superstitious)

That's why I would prefer the ability to save the recovered files to a 'save' location before opening..
Comment 13 Thomas Lendo 2018-01-11 08:29:56 UTC
(In reply to Telesto from comment #12)
[..]
> That's why I would prefer the ability to save the recovered files to a
> 'save' location before opening..
Looks like a new bug. I think that shouldn't be discussed here.

Note: Such a save feature should be done automatically with a checkbox in Tools > Options or in the recovery dialog because in doubt users will cancel the question (if done as new pop-up dialog) to save files before opening due to acting in haste. How should users know when it's necessary to save before opening? It's like gambling.

(In reply to Heiko Tietze from comment #10)
> Created attachment 139033 [details]
> Mockup for an improved dialog
> 
> All checkboxes are set on by default, which makes the dialog equal to the
> current workflow. But unlike today the user can unselect one or all files
> and start the 'Recover selected' operation.
How's about changing the 'Recover selected' button text to 'Recover all' automatically if all files are selected?
Comment 14 Telesto 2018-01-11 11:41:53 UTC
> > That's why I would prefer the ability to save the recovered files to a
> > 'save' location before opening..
> Looks like a new bug. I think that shouldn't be discussed here.

YES and NO. The matter isn't well-thought-out, in my opinion. It started with a confusing dialog (I agree). The solution is a new design, changing the recovery behaviour. I'm not totally convinced about that. Do we really want to select individual files?

I'm missing a proper argument for such change. What do we want to achieve? What does the user want?

Normally I would expect full recovery of all my open documents (if everything works as expect). I only want to select individual documents under exceptional cases:
* Not interested in all the files. 
* A crashing file is included in the recovery dialog

Most problematic is a failing recovery, which makes LibreOffice crash again. This needs a more robust implementation (in my opinion).

A main cause of a crash loop is - in my experience; (I'm I wrong here?) - the immediate file opening of all the recovered files after recovery. That why a proposed a change into the recovery proces itself. Between recovery and file opening. There needs to be a way to recover most of the files safely & identify the crash culprit without going into the recovery process over and over. The possibility to open recovered files incrementally and marking the crashy culprit as bad (or something like that). That's why I ask to have the to 'save' the recovery files before opening. It's the way how I would handle it manually.
Comment 15 Heiko Tietze 2018-01-11 12:22:18 UTC
(In reply to Telesto from comment #14)
> What do we want to achieve?

Making clear how the recovery works - wouldn't expect users to disable single files from the list but having the option supports to understand the procedure. Also we get two clear interactions: okay, cancel with better labels.

And the issue with crash loops is not a UX topic.
Comment 16 mattreecebentley 2018-02-08 23:50:12 UTC
*** Bug 115564 has been marked as a duplicate of this bug. ***
Comment 17 mattreecebentley 2018-02-08 23:51:34 UTC
Also present for Writer. Individual files should not be selectable if the only option is to recover all. That's just plain ridiculous...
Comment 18 Regina Henschel 2018-03-22 13:55:28 UTC
Please consider special case of one file to be recovered, see bug 103607.
Comment 19 Mike Kaganski 2018-03-22 14:02:33 UTC
*** Bug 116560 has been marked as a duplicate of this bug. ***
Comment 20 Mike Kaganski 2018-12-20 19:37:05 UTC
A code pointer: RecoveryDialog (declared in svx/source/inc/docrecovery.hxx) should disable selection in the list it creates and operates.
Comment 21 Daniel 2020-10-11 16:12:43 UTC
I would like to work on this, but there seems to be contradicting information...

I see 2 things that need to be done to clear up any confusion:

1- Disable list item selection in the dialog
2- Change button labels to 'Recover All' & 'Discard All'

Any objections/ other suggestions?
Comment 22 Heiko Tietze 2020-10-12 07:10:42 UTC
(In reply to Daniel from comment #21)
> Any objections/ other suggestions?

If you follow my suggestion it's a bit more effort. Your proposal keeps the current situation, makes it a bit more clear what happens, but does not allow to recover only a (few) particular file(s), which was Dan's workflow.
Comment 23 Daniel 2020-10-12 14:19:50 UTC
Ok, sure.
I will implement your proposed solution from comment 10.
Comment 24 Daniel 2020-10-19 13:52:29 UTC
Created attachment 166511 [details]
screenshot

It does not seem like the checkbox in the header is really supported.

- On Windows the header will just remain empty (see screenshot)
- On Linux it does render, but the widget cannot be clicked directly, the column header must be made clickable and then the checkbox state updated manually

So I suggest to make a separate button on the bottom left to select/unselect all
Comment 25 Mike Kaganski 2020-10-19 14:27:57 UTC
(In reply to Daniel from comment #24)
> So I suggest to make a separate button on the bottom left to select/unselect
> all

That looks fine; please do :-)
Comment 26 Heiko Tietze 2020-10-20 07:28:25 UTC
(In reply to Daniel from comment #24)
> So I suggest to make a separate button on the bottom left to select/unselect
> all

I would rather not have the select-all feature than adding a dedicated button for it. The checkbox on top is a common UI element with a clear relation to it's subordinate controls. Buttons run an action and using it to set something in the UI is bad usability.

Since the number of items in the list is typically below 10 or even less than 5 it's pretty easy to de/activate each. Furthermore, it's not so clear why a user wants to recover one document while she doesn't for another. Makes only sense if you know what caused the previous crash.
Comment 27 Mike Kaganski 2020-10-20 07:31:36 UTC
(In reply to Heiko Tietze from comment #26)
> Furthermore, it's not so clear
> why a user wants to recover one document while she doesn't for another.
> Makes only sense if you know what caused the previous crash.

OMG. Writing this in a bug that is all about that, starting with:

> 4. In the recovery dialog, click a spreadsheet you don't care about, then
> Discard

Users need it. Users feel it natural. No "All" button is fine; starting the discussion again is useless.
Comment 28 Mike Kaganski 2020-10-20 07:33:41 UTC
(In reply to Dan Dascalescu from comment #0)
> I clicked one of the sheets and then Discard.
> ...
> 4. In the recovery dialog, click a spreadsheet you don't care about, then
> Discard

But please make sure that user can't make wrong thing, and imagine that "Discard"-like action will be applied only to the checked items, if it will not.
Comment 29 Telesto 2020-10-20 08:24:23 UTC
I'm likely not totally up to speed here about the functioning of the new dialog

But is this case covered too: In principle I'm out to recover everything. On the first recovery - recovering all together - I hit a crasher. Next I want to selectively recover. So recovering 'one by one'. Not that recover selected means, recover those and discard the rest automatically (see also comment 6 comment 8)
Comment 30 Daniel 2020-10-20 09:24:59 UTC
Created attachment 166536 [details]
recoverydialog

(In reply to Telesto from comment #29)
> But is this case covered too: In principle I'm out to recover everything. On
> the first recovery - recovering all together - I hit a crasher. Next I want
> to selectively recover. So recovering 'one by one'. Not that recover
> selected means, recover those and discard the rest automatically (see also
> comment 6 comment 8)

It was my understanding that everything (recover and discard) happens when the user selects 'recover selected'.

If the user is allowed to recover one after the other then it is not clear at which point the discarding should happen, is this up to the user to discard separately from the recover...

The status column will have text "Will be discarded" for unselected entries, the column header is called Recover and the button texts updated "Recover Selected" and "Discard All" (see screenshot, *desc not updated yet!)

Does this make it clear enough for the user?
Comment 31 Telesto 2020-10-20 09:53:32 UTC
(In reply to Daniel from comment #30)
> If the user is allowed to recover one after the other then it is not clear
> at which point the discarding should happen, is this up to the user to
> discard separately from the recover...
> 

Leaving this to the experts.. first of it's already the question of this should implemented or not :-)
Comment 32 Timur 2020-10-29 10:45:48 UTC
*** Bug 112188 has been marked as a duplicate of this bug. ***
Comment 33 Timur 2020-10-30 17:37:42 UTC
*** Bug 137878 has been marked as a duplicate of this bug. ***
Comment 34 Eyal Rozenberg 2021-03-31 14:32:40 UTC
Reporter of the (not-)dupe bug 137878 here...

* It seems like the more thorough resolution may involve potential changes to recover & discard functionality; and that a long time has passed without the issue being resolved. I would this suggest that potential workflow improvements about which there may not be consensus, from a shorter-term fix of the misleading aspect of the dialog: Disabling selection and clarifying the button labels.
* My non-dupe bug 137878 should also be considered when re-thinking the workflow here, since resolving it involves altering the relative timing of recovery-related actions.
* In light of the above, I also suggest that a new bug be opened for suggesting/discussing/finalizing a better recover & discard workflow / UX.
* I'll say that, personally, I'm often only interested in restoring some files rather than others. I also have further thoughts on recover & discard which I'd rather not throw into the mix here.
Comment 35 Elliotte Rusty Harold 2021-03-31 15:07:42 UTC
The simplest solution by far: recover all. Don't even ask. No dialog. No checkboxes. No buttons. Preserve the user's data.
Comment 36 Mike Kaganski 2021-03-31 15:12:06 UTC
(In reply to Elliotte Rusty Harold from comment #35)

... and let user have problems from being unable to open the program when restore process crashes (some invalid data); or being unaware that the document that they see opened on screen is the restored one, and may differ from the saved version, and may be incomplete (because of restored copy is not necessarily correct) ...

I even simpler solution: never crash. Even on power outages.
Comment 37 Elliotte Rusty Harold 2021-03-31 15:14:30 UTC
If the program crashes because bad data is fed to it, that is a separate bug and orthogonal to the question of proper behavior and UI.
Comment 38 Mike Kaganski 2021-03-31 15:16:42 UTC
(In reply to Elliotte Rusty Harold from comment #37)

... and you surely suggest that those don't happen in practice, and thus no user will suffer from the "proper behavior" from your proposal?
Comment 39 Eyal Rozenberg 2021-03-31 16:30:57 UTC
(In reply to Elliotte Rusty Harold from comment #35)
> The simplest solution by far: recover all. Don't even ask. No dialog. No
> checkboxes. No buttons. Preserve the user's data.

That is not a simple solution. First, it's more coding than the simple solution suggested by @DanDascalescu and others. Second, it will result in:

* An unexpected delay on startup.
* Surprising error dialogs for the user regarding missing, unreadable or corrupt files (unless the dialogs are re-worked, and then again it's the opposite of a simple solution)
* Possible damage to physical media trying to read, and perhaps write, to directories which the user may not want accessed due to partial failure of the filesystem or disk.

So no, that is not simple and I reiterate my suggestion to not try to "fix recover & discard" with this bug.
Comment 40 b. 2021-05-01 09:55:57 UTC
long discussion already ... 

ran into the special situation where one file crashes and hinders saving the data from the others, 

proposal - if not already mentioned - 

apply checkboxes left of the files listed, 

preset all checked, 

one button 'proceed with recovering of the selected files', 

no 'discard' or 'discard all' buttons, 

is some effort for the user to deselect, reminds him on 'doing unusual', 

but gives ability for meaningful way out between crash or loose data,