Bug 451745

Summary:	Undo (Ctrl+Z) can invisibly undo stuff that was done in other folders
Product:	[Applications] dolphin	Reporter:	php4fan
Component:	general	Assignee:	Dolphin Bug Assignee <dolphin-bugs-null>
Status:	CONFIRMED ---
Severity:	grave	CC:	kfm-devel, nate
Priority:	NOR	Keywords:	usability
Version:	21.12.2
Target Milestone:	---
Platform:	openSUSE
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description php4fan 2022-03-20 22:28:18 UTC

STEPS TO REPRODUCE
1. Navigate to some folder A that contains a few files
2. Delete and rename a few files in that folder
3. OPTIONAL STEP: Let several hours pass while you don't touch Dolphin (actually, you may very well use Dolphin to navigate, open and close folders, but just never do any undoable actions such as rename or delete files), and mainly use other programs where you do your work, which may include editing some of the files you renamed at step 2
4. Back to Dolphin, navigate to a completely unrelated folder B
5. Hit Ctrl+Z one or more times

NOTE: step 3 is optional, just to demonstrate the potential catastrophic effects of this bug. You can omit step 3 and still clearly reproduce and (hopefully) understand the issue.

EXPECTED RESULT
Nothing should happen. Or if Ctrl+Z does do something, you MUST see it. Definitely it should not do something that you can't see, with no warning, and definitely it shouldn't do something in any folders other than the one you are looking at.

OBSERVED RESULT
Ctrl+Z undoes the latest thing you did in Dolphin, even if it was in another folder, even if it was hours ago, even if it involves files that in the meantime have been touched by other processes, and even if you don't see it and have no clue it's happening.
So in the case of the steps above, it will undo whatever you did at step 2 in folder A, but you won't see any of it because you are in folder B. Given that nothing seems to happen when you hit Ctrl+Z, if you are expecting something to visibly happen because you think the last thing you did was something else, you are likely to hit it more and more times, which means you are INVISIBLY undoing more and more actions.

The fact that there is "Undo" but no "Redo" (which is a separate huge bug, or design flaw) makes this even worse.

This is an absolute disaster that can cause data loss without even realising. It should not be underestimated.

SOFTWARE/OS VERSIONS
Operating System: openSUSE Tumbleweed 20220207
KDE Plasma Version: 5.24.0
KDE Frameworks Version: 5.90.0
Qt Version: 5.15.2
Kernel Version: 5.16.5-1-default (64-bit)
Graphics Platform: X11
Processors: 8 × Intel® Core™ i7-1065G7 CPU @ 1.30GHz
Memory: 7.3 GiB of RAM
Graphics Processor: Mesa Intel® Iris® Plus Graphics

Comment 1 Nate Graham 2022-03-27 17:27:16 UTC

Yeah, when Undo changes something not visible, we should show the user what happened, and definitely let them Redo afterwards.

Comment 2 php4fan 2022-03-27 17:52:18 UTC

> Yeah, when Undo changes something not visible, we should show the user what happened

That is absolutely a huge part of the issue but that's not all.
If that "something not visible" is "something that was done in another tab/window", that shouldn't be undoable in the first place from the current tab. Each tab should have its separate undo history (which should get destroyed when you close that tab).

Think of when you edit files in multiple tabs or windows in any modern text editor (or other kind of editor, e.g. images in GIMP). Would you imagine hitting Ctrl+Z in a tab, and undoing something that was done on another file in another tab? No, right? Even if that brought focus to the affected file and scrolled to the affected position and made the (un-)changes visible (which is what happens when you undo in the current focused file), that wouldn't make it acceptable. And when you close and reopen a file, you don't expect to be able to undo stuff that was done before closing and reopening the file. 

Analogies don't automatically hold, but I'm pretty sure this particular analogy holds quite well here.

Comment 3 Nate Graham 2022-03-27 21:24:47 UTC

> Each tab should have its separate undo history (which should get destroyed when you close that tab).
Yeah, that seems reasonable.