GNOME Bugzilla – Bug 596841
Selecting a folder to save to loses focus on file name
Last modified: 2018-05-02 14:49:56 UTC
https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/439239 This bug has occured multiple times before, however the fixes no longer seem to be working: https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/130224, https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/22322, https://bugzilla.gnome.org/show_bug.cgi?id=468445, and their duplicates. In short: the task of saving a file is broken as soon as the user chooses a different folder. Typing no longer renames the file but instead starts searching for folders in the list, however the text selecting the filename is still highlighted. I believe the task of naming a file to save is much more common than having to do a text search to find a folder to save to (they're already alphabetically ordered). Accordingly, the filename should never lose focus, even when the user is active inside the other parts of the file save dialog (eg making/selecting a folder to save to). To reproduce: in Gedit, make a new file and File->Save as. Click a folder and then start typing. A similar thing happens if you save a picture in Firefox.
I have the same issue. There should be a setting to change the behavior from the default to one where double clicking folders does not remove focus from filename while single clicking in folders file area does activate the find function. The default behavior of changing the focus when a subfolder is double clicked should at least take the highlighting off the filename as it gives the illusion that the focus is still on the highlighted text when it is actually on a find popup which does not popup until you start typing.
I have the same issue and as a user I have the same priority as Scott when it comes to naming the file vs. finding the folder by typing. I propose the finding-by-typing function could be activated either: - When the user is hovering over over the location box. The filename field would in any other case be active. - When Ctrl+F is pressed. This seem to be an established standard for finding strings in general, seen mostly in text editors.
We have two elements competing for "just type" text input: (1) type-ahead search and (2) filename entry. (1) "Just type to search" is an emerging pattern in GNOME. It features in both GNOME 3 apps and the Shell. Requiring Ctrl+F to search would go against the user expectations we are building. (2) The save dialog should provide a seamless file saving experience. The two most common steps are: (a) give it a name, (b) choose a location. Doing (a) then (b) is currently seamless. Doing (b) then (a) requires manually focusing an entry widget, which breaks what would otherwise be a seamless experience for both workflows. I find it very hard to choose whether (1) or (2) should take priority. But I think making it a user preference is a bad idea. Can we have both (1) and (2) in a single element? These are the only relevant use cases for (1) that I can think of: - find a folder where to save the file - find a file to replace Actually, (2) already covers both of these use cases. If I start typing the name of a file or folder in (2), it finds matches and shows them as suggestions. It's doing roughly[0] the same thing (1) does. Therefore, I propose that the type-ahead find in the save dialog. In addition to the rationale above, this would converge with nautilus, which has disabled type-ahead as well. [0] The most noticeable difference being that the suggestions are not case insensitive. I think they should be, anyway. Also, picking a folder suggestion should change the location right away (currently it requires hitting Return). Other than those two issues, I believe that the suggestions feature fully
(I'm so sorry, I hit "commit" by accident while typing. Bad trackpad. Allow me to complete the previous comment:) [...] I believe that the suggestions feature fully replaces the need for type-ahead find.
Noticed this bug reference in IRC logs the other day... and I have been encountering the same annoying behaviour. Should the treeview in the file chooser widget accept focus ? Would it make sense to just set 'can-focus = FALSE' for the treeview widget ?
Created attachment 243682 [details] [review] Patch to remove focus capability on the GtkFileChooserDefault's treeview Proposed patch, not sure if it makes sense to do this, but it seems to improve the file saving experience from Glade.
making an active ui element nonfocusable is basically always the wrong answer.
*** Bug 766417 has been marked as a duplicate of this bug. ***
(In reply to António Fernandes from comment #3) > (2) The save dialog should provide a seamless file saving experience. The > two most common steps are: (a) give it a name, (b) choose a location. Doing > (a) then (b) is currently seamless. Doing (b) then (a) requires manually > focusing an entry widget, which breaks what would otherwise be a seamless > experience for both workflows. For me the most intuitive approach is (b) then (a), because I usually first want to determine where to save a file, and then based on the already existing file names want to provide the file name. Especially, because the file name is already highlighted, I have the impression that when I start typing, the default file name will be replaced, but instead the "just type to search" is annoyingly activated. This behavior is the most non-intuitive one in Gnome in my opinion. Would it be possible to at least remove the highlight (which suggests the focus) from the file name? This would clearly indicate that you have to select the file name before you start typing. However, my preferred solution is to disable that the "just type to search" kicks in unexpectedly, because I'm seldom using it.
Actually, to be more precise: the file name does loose the focus highlight, but the default text "Unsaved Document 1" stays selected (which I confused with the focus indicator). The annoying part is that when you use the mouse to give focus to the file name box, the selection is lost (while I always want to replace the full text). Using the keyboard to give focus to the file name again requires me to hit <tab> five times.
I see two issues regarding this case: 1. the workflow of saving a file 2. the wrong focus The workflow is a matter of taste and entering the file name before choosing the location is obviously the approach intended by the dialog. None of these workflows is better than the other. This just means people who prefered it the other way around (choosing location before entering the file name) have to change their workflow. (By the way, ALT+N will bring the focus back to the file name.) The other issue with pretending that the file name widget still has the focus although it doesn't have it after clicking somewhere else, is simply a bug which should be fixed. Having a highlighted text in a widget is for the majority of users an indication that this widget has the focus. This should be fixed by removing the highlighting from the file name widget as soon as the user clicks somewhere else.
*** Bug 756907 has been marked as a duplicate of this bug. ***
(In reply to Ralf Hersel from comment #11) > The other issue with pretending that the file name widget still has the > focus although it doesn't have it after clicking somewhere else, is simply a > bug which should be fixed. Having a highlighted text in a widget is for the > majority of users an indication that this widget has the focus. This should > be fixed by removing the highlighting from the file name widget as soon as > the user clicks somewhere else. Nothing is being 'pretended'. The issue is simply that the standard themes draw both focused and unfocused text selections with the same background colour, and the presence/absence of a similar highlight around the border of the entry is not sufficiently striking for people to realise the difference. See https://bugzilla.gnome.org/show_bug.cgi?id=770941 for more on this. Let's try to keep the issues of 'stop focussing' vs 'fix the theme' distinct.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/326.