Bug Hunting Session
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: difficultyBeginner, easyHack, skillCpp
: 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: 2018-12-21 03:49 UTC (History)
13 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

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.