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
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?
From comment #1 set status to NEEDINFO, please set it back to UNCONFIRMED once requested informations are provided. Best regards. JBF
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.
(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 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.
(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)
(In reply to Telesto from comment #6) > 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. Not a corner case for me, but more a real life need :)
(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.
(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?
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.
Decision was made in the design meeting 2018-Jan-10. Removing needsUX.
(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..
(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?
> > 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.
(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.
*** Bug 115564 has been marked as a duplicate of this bug. ***
Also present for Writer. Individual files should not be selectable if the only option is to recover all. That's just plain ridiculous...
Please consider special case of one file to be recovered, see bug 103607.
*** Bug 116560 has been marked as a duplicate of this bug. ***
A code pointer: RecoveryDialog (declared in svx/source/inc/docrecovery.hxx) should disable selection in the list it creates and operates.
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?
(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.
Ok, sure. I will implement your proposed solution from comment 10.
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
(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 :-)
(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.
(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.
(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.
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)
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?
(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 :-)
*** Bug 112188 has been marked as a duplicate of this bug. ***
*** Bug 137878 has been marked as a duplicate of this bug. ***
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.
The simplest solution by far: recover all. Don't even ask. No dialog. No checkboxes. No buttons. Preserve the user's data.
(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.
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.
(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?
(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.
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,
*** Bug 142563 has been marked as a duplicate of this bug. ***
Almost finished yet abandoned patch at https://gerrit.libreoffice.org/c/core/+/104385
*** Bug 140964 has been marked as a duplicate of this bug. ***
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a9c8ac0605fd1d19e1d79b54804b610a64a8a056 Resolves tdf#114508: Individual selection in recovery dialog It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thanks to Danie Truter for most work on this issue.
*** Bug 150862 has been marked as a duplicate of this bug. ***