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.
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?
(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.
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.
(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!