-
Notifications
You must be signed in to change notification settings - Fork 6.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[File Explorer] Feature Suggestion: Protect against accidental Undo/Redo (Ctrl+Z/Ctrl+Y) #16337
Comments
This feels best for Windows Feedback hub, I don't see PowerToys creating this utility. Based on what you said, you could maybe disable ctrl+Z for explorer.exe via KBM |
@crutkas thanks for the response, yeah sadly I personally don't have any faith in the possibility of Feedback hub entry convincing any Windows developers when it comes to these obvious & vital UX issues (unless they are actual bugs). Having a community-driven open-source modification would be the last resort, especially for users unwilling to install arbitrary third party binaries (workarounds of which may break in the future). I understand that priorities of this project differ from general-purpose Explorer improvements, so I'm hoping this decision can be at least revisited in a few years (if Windows won't acknowledge it until then, which it certainly won't). For future reference, I'd appreciate if you could briefly elaborate on any reasons why it'd be impractical for PowerToys to implement this feature; i.e. does the Explorer provide insufficient API for enrichment by new prompts or protection against destructive operations, is it unreasonable to show the history of actions, or is it just too difficult for the PowerToys team to ensure forward compatibility with new Windows updates? And I as mentioned regarding Keyboard Manager's Shortcuts (there is no point in having a safety feature if it isn't fully tested and contained in one place), are you of the opinion that it's unreasonable to add this as a predefined option (any time in the future), so that it'd be easier for users to set up the sane defaults after they reinstall their OS? Thanks for your feedback :) |
I think the problem is that there's no public explorer API to do this. |
Description of the new feature / enhancement
File Explorer intuitively supports the typical feature of Undo/Redo, both as a shortcut (Ctrl+Z/Ctrl+Y), and from a context menu:
However, there is a risk that we usually don't notice. One that you cannot unsee, and it will drive your anxiety once it enters your awareness like some virus. Disclaimer: continue reading at your own risk (mental health will be impacted if you're an optimist).
https://www.google.com/search?q=ctrl+z+explorer
First there is the risk of a misclick (wrong keypress). Imagine a scenario of doing Undo in your text editor, Alt+Tabbing into Explorer, copying a file, etc. If you now accidentally press Ctrl+Z in ANY of the Explorer Windows, you won't have any idea about what just happened. It may be nothing, or if you've kept hibernating OS instead of shutting it down every night, you may have just moved a directory with which you've last interacted 2 months ago. There is no feedback, no prompt, no file name, no destination path. Something has happened somewhere. And because Undo isn't limited to one usage, maybe you accidentally press it several times (or your old keyboard detects the
Z
key twice, ouch).As a simplest option, my suggestion is to provide a setting that globally disables any such global Explorer-wide interaction, and instead displays a prompt where the user has to confirm this choice, but only after being provided with the exact information about the source and destination files. In case of a Redo, this could include some metadata like the date/time when the Undo has been performed (which is especially suspicious if this wasn't a short time ago).
Some of you may be still skeptical, believing that it doesn't matter if your files randomly move to a completely different directory, or get renamed. If the only thing that convinces you is absolute data destruction, let's go try these repro steps:
a\file.txt
tob\file.txt
a\file.txt
Result? Why, of course,
b\file.txt
permanently overwritesa\file.txt
without any confirmation dialog. This is a feature by design and not a bug. I mean sure, it could be relatively easy to recover contents of a deleted file if you're lucky, but not if you don't know which file was removed. (By the way, the result of Undoing a Copy is also a permanent deletion, obviously, so be careful to never lose your original 🤔)As another aspect of the feature request, I'd suggest adding some way to display the history of these actions, and to make it at least temporarily persisted. After all, after Redo you cannot do Undo again. It's not like there was enough time for this feature to be implemented in Windows 10, we just need to be careful never having to resort to doing a Redo, which brings me to another use-case of why the Redo should definitely always display a prompt. It's easy to handle the mistake of Undo, because it just reverts your action, but if your last action was Undo, you're one step from doubling down on your mistake. In addition, there are sequences like Undo + other action that also remove the Redo (just like in text editors where the inability to view a non-linear history is just as annoying). Oh, and did I mention that you cannot do Redo twice?
One of the examples where we may need to be extra careful is when interacting with external drives or similar "network" devices, because not only can the file interaction span more of them, but if one gets disconnected, you automatically lose its context of history. But this also applies to your local system, because there are scenarios like OS restarting (updating) or crashing, where you may be in a situation where you've just done an Undo without being aware of which files were impacted. (Especially if that's a larger file operation, making you wait until it finishes before you're allowed to Undo. Canceling a directory Copy in the middle of operation doesn't create any record that you can Undo, of course...) Even in the simplest scenario, the worst case basically occurs if you make an accidental Undo or Redo right before getting locked out of the system before being able to revert the action, because you won't be able to access the history anymore.
You know what, while I'm at it, can't we just generalize this feature along the lines of "Safe Explorer File Interaction", so that it includes even accidental drag & drop of some directories while navigating between them? It takes so little effort to corrupt your %appdata% installations or any other file hierarchy, especially if there's no visual feedback, and using the infamous Undo is the only way to make sure you recover correctly... Though at least the drag & drop is something we actually use, so with proper Undo safety this may be acceptable.
Scenario when this would be used?
As a power user, if you install PowerToys on each machine where you work with important data, you will increase your sanity by a large margin thanks to keeping this feature enabled by default. If anyone actually uses Ctrl+Z with files so often they are unwilling to have to perform one or two additional keystrokes for each (irreversible) interaction with filesystem, they can disable this feature. Even in that case, at least the history of actions could be available for users with additional metadata to be able to manually perform any recovery steps.
Supporting information
dweundo
"Disables CTRL + Z & CTRL + Y while Explorer is the active Window". It seems this use-case could be also handled byKeyboard Manager
'sShortcuts
in PowerToys directly. Needless to say, for purposes of this issue it'd need to be available directly as an option (preferably as a default) rather than expecting users to be aware of the need to configure this manually. There is no point if the use-case isn't fully tested, i.e. maybe there are more indirect ways to invoke this (in addition to context menu & buttons in Quick Access Toolbar).Horror stories
The text was updated successfully, but these errors were encountered: