Bug 401937 - Too easy to replace current filename with name of another file and no easy way to get the original back
Summary: Too easy to replace current filename with name of another file and no easy wa...
Status: CONFIRMED
Alias: None
Product: frameworks-kio
Classification: Frameworks and Libraries
Component: Open/save dialogs (show other bugs)
Version: unspecified
Platform: Archlinux Linux
: NOR wishlist
Target Milestone: ---
Assignee: David Faure
URL:
Keywords: usability
Depends on:
Blocks:
 
Reported: 2018-12-10 00:12 UTC by magiblot
Modified: 2019-06-10 13:38 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Link to video reproducing case of user frustration (66 bytes, text/plain)
2018-12-10 00:12 UTC, magiblot
Details

Note You need to log in before you can comment on or make changes to this bug.
Description magiblot 2018-12-10 00:12:42 UTC
Created attachment 116819 [details]
Link to video reproducing case of user frustration

SUMMARY

It is not strange for a user using the Save As dialog to click on other files and folders before making their final choice, even if it's by mistake. However, by doing this they might easily lose track of the original filename of the file they were intending to save -- and it seems the interface does not help recovering it.

STEPS TO REPRODUCE
1. Run the 'Save As' dialog from an application which uses it (e.g. Kate or Falkon). Make sure to have a filename suggestion (e.g. avoid saving an Untitled document in Kate because that doesn't provide any).
2. Click on a file from the file list but do not exit the dialog.
3. The filename suggestion gets replaced by the filename of the chosen file.

OBSERVED RESULT

The dialog interface doesn't seem to provide any way to recover the original suggested filename of the file that is being saved. In order to do so, the user then has either to copy the filename before interacting with the file browser or to cancel the operation and open the dialog again.

EXPECTED RESULT

I would have expected to find some visual functionality for recovering the original filename (e.g. an 'undo' icon in the left side of the text box, in a similar fashion to the backspace one which is already shown when editing the filename), or the original filename to be the first in the dropdown list, or even an option for this in the right-click context menu.

SOFTWARE/OS VERSIONS

Operating System: Arch Linux 
KDE Plasma Version: 5.14.4
Qt Version: 5.11.2
KDE Frameworks Version: 5.52.0
Kernel Version: 4.19.4-arch1-1-ARCH
OS Type: 64-bit

ADDITIONAL INFORMATION

A possible worst-case scenario is when downloading a file from internet. In this case, there probably is no file in disk with a similar name they can recover the original filename from. If the user loses the original filename by mistake and they didn't copy it to clipboard, their only way to recover it is by closing the dialog and following the download link again -- and there are certain websites which will only provide a single chance to download the file.

I am enclosing a video capture of a similar situation of user frustration. Because of a possible bug, the original filename is lost when changing directories and there is no way to get it back -- except pasting it from the clipboard if the user already knew it was going to happen, which was my case.

Thank you very much.
Comment 1 Nate Graham 2018-12-11 18:34:53 UTC
This is not expected behavior at all. When you click on "Home" in the places panel sidebar, the filename is not supposed to disappear. I canot reproduce this issue with any of the file dialogs I tried it on in other KDE apps. Maybe a Falkon problem?
Comment 2 magiblot 2018-12-11 19:09:54 UTC
(In reply to Nate Graham from comment #1)
> This is not expected behavior at all. When you click on "Home" in the places
> panel sidebar, the filename is not supposed to disappear. I canot reproduce
> this issue with any of the file dialogs I tried it on in other KDE apps.
> Maybe a Falkon problem?

Thanks for taking a look at this, Nate. However, this is not the issue I'm trying to report. What I am claiming is that there is no way to recover the filename once it's lost, be it because the text field clears or because the user clicks on another file by mistake, which is more common. If there was a way to recover the original filename, then the bug you spotted wouldn't matter. Please read the initial message carefully for more information.

Nevertheless, I have found a way to reproduce the text field clearing bug (it's not Falkon-related) and will open a separate bug report, because it's not the point of this one.

Please restore the previous product and title of this bug report.

Lots of thanks.
Comment 3 magiblot 2019-05-23 12:43:37 UTC
This could be worked around enabling Undo/Redo in the filename field. Surprisingly, the Filter field already has this feature.

For it to be useful, the Undo history should not be cleared when selecting a file from the folder view or an entry from the Name dropdown list.
Comment 4 Nate Graham 2019-06-10 13:38:03 UTC
(In reply to magiblot from comment #3)
> This could be worked around enabling Undo/Redo in the filename field.
> Surprisingly, the Filter field already has this feature.
> 
> For it to be useful, the Undo history should not be cleared when selecting a
> file from the folder view or an entry from the Name dropdown list.
Hey, that's not a bad idea!