Improve Save As Dialog Box (focus issues)

could you take an screenshot of that dialog ? it seems you're referring to the gtk file chooser.

The Save As dialog is not in any way related to Nautilus.

My apologies, I thought it was part of Nautilus.

I have attached a screenshot.

Here's the Windows "Save As" dialog for comparison.

I can confirm this. Also it is valid for OHPC.

Here here, please fix this!

The box it is focusing on does not let you type anything anyway, it is a listbox for the file extensions.

Save as should be focusing on the name box of the item being saved, so you can type what you want it to be saved as.

Came to nominate this for 100 paper cuts. Glad to see it's already reported.

Also came to nominate this as a paper cut - would be glad to see it fixed finally!

P.S. OS X also returns focus to the filename box, same as Windows... probably shows that that's how it should be done...

This is not an obvious usability flaw, and may even be considered a feature as-is. The behavior is similar on Mac OS -- typing while browsing the Save dialog jumps to files and folders whose names begin with the letters typed. This enabled advanced users to quickly jump to their targets in dense directories. Changing this behavior would be seen as a serious regression by many, so it needs a user testing and thorough interaction analysis. Therefore, it's not a paper cut.

Thanks for your note David. I'm not suggesting to change the behaviour of the Find As You Type feature that allows quickly jumping through directory structures by typing folders' initial letters. Personally I use this all the time and think it's great.

The main issue here, especially for non-advanced users, is Scenario 1 (above), where the find as you type feature is not used (ie the user double-clicks on folders to define the save location). In this case, the focus is not returned to the Name field after double-clicking on folders. This means that after finding the desired location, the user has to move the mouse back to the Name field, highlight the existing name (usually something like "Untitled 1"), then type a name in and press Save.

In Windows, the focus is returned to the Name field after double clicking on a folder. But Find as you type is also available on Windows for advanced users - by single-clicking in the folder area (either on a folder or in an empty space), focus is switched to the folder area and find as you type can be used - focus only jumps back to the Name field if the mouse is used to double click a folder. If enter is pressed to enter a sub-folder, focus remains in the folder area.

My guess is that Ubuntu's interface was designed with the assumption that the user would first name the file, then choose the location to save it. I don't work this way and my guess is that I'm not alone. I like to see the contents of a folder before choosing how to name a new file.

I don't have a Mac to hand but I'll try and have a play with one to see how they do it over the next couple of days - I'm sure they've got a smart solution to this problem, and their layout is similar to Ubuntu's (with the name field at the top).

In summary: If a folder is double clicked with the mouse, focus should jump to the Name field. That is the only change I am proposing for this paper cut. If enter is used to enter a folder, focus in the folder area should be maintained (the current behaviour). Advanced users would not be affected, but non-advanced users would be saved from a lot of clicking.

Ok, I checked on Mac OS (10.5.something) and they solve it as follows:

When navigating folders by keyboard, pressing tab ONCE takes you from the folder list straight back to the Name field, as it does in Windows (the layouts are different, but the effect is the same).

There are only four "tab stops" in the Mac Save dialog box: Name, Find, Places (equivalent) and the Folder List area - in that order. This works excellently when using only the keyboard to save a file in a specific location. I've never really used a Mac, but I was able get the hang of this in seconds.

Unlike Windows however, using the mouse to navigate the folder structure does not automatically return focus to the Name field - you have to do it by tabbing (once) or by using the mouse.

I have also noticed that in Ubuntu it is not possible to tab through all the fields as it is on both other OSs, as the Name field uses tab to autocomplete (it just shows "No match" when tab is pressed).

Unintuitively, the down arrow can be used to move away from the Name field instead. You can use the arrow keys to move through different fields until you reach the Places list, where behaviour changes again and they start moving up and down the Places list. Only tab will then take you from Places to the folder selection list. With a lot of upping and downing and tabbing it is actually possible to save a file in a specific location using the keyboard, but it is far from quick, easy or intuitive.

I think the whole save dialog needs looking at from scratch, but meanwhile I believe usability could be improved by:

1. Reverting focus to the Name field if a folder is double-clicked using the mouse (familiar Windows behaviour, which does not impact keyboard-using advanced users in any way).

2. Making the Name field the next tab stop after the folder selection list (familiar Windows and Mac behaviour). Keyboard using advanced users will welcome this too.

Glad this was reported, sad to see it was marked invalid, it is definitely annoying. gdi2k's solution seems reasonable.

Very disappointed to see this marked invalid. When you're saving, most of the time you are creating a new file. The current behavior is only helpful if you want to overwrite an existing file. It is clear to me that the most useful behavior would be for focus to default to the filename field.

I could not disagree more that "This is not an obvious usability flaw, and may even be considered a feature as-is."

I suspect the bug report was either not fully read or fully understood by David S, otherwise he would not have written that - he must have thought I was wanting to eliminate the find as you type feature, which is not the case at all.

I know the Save dialog is not something that developers use very frequently, but anyone that ever tries to get real-life knowledge workers to use OpenOffice on any Gnome-using OS will run into this complaint very quickly (I know). Saving a new document is just too hard.

By the way, KDE (Qt) does this better too; choose a folder where you want to save your document and a SINGLE tab takes you back to the file name entry field (just like on Windows and Mac OS).

Despite all being very different, 3 of the top 4 desktop GUIs allow you to jump from the folder selection space to the file name entry field with a SINGLE push of the tab key - maybe that's a hint that Gnome is doing it wrong.

I disagree with David that the current behavior is good, but I agree with him that this bug report is not valid as a papercut.

Making Tab from the folder list navigate to the Name field would require either (a) introducing a Mac-style focus model as default in GTK (i.e. only text fields and listboxes get focused, not buttons etc), or (b) rearranging the Save dialog so that the Name field is below the folder list, as it is in the Windows dialog, or both. Either of these changes would have complex effects elsewhere that would need to be designed in detail. I suggest contacting GTK+ developers directly about the issue.

This is definitely an irritating 'bug/feature' regardless of who things what about it; one of the most common times to encounter it myself is in saving things from a web browser, as most people will do once in a while; if you want to browse for a folder to put it, but rename the document (which happens every time I download an academic paper for example) then you would logically begin typing, as the name is 'highlighted'.

I believe part of the issue is the colour of the highlighted text; it looks the same whether the name box is in focus or not; I am aware of the fact that there is a little highlight around the edge of the name box when it is highlighted, but apparently forget that every time I go to save something; if the highlighting of the text were changed to say grey when the box was not in focus, I think it would be much more clear at least. Not a solution in my mind, but at least a way to make it more obvious what is happening.

/RAGE at this being marked as invalid for OHPC. This has been an annoyance to me for as long as I can remember using GTK+ apps on windows or linux (early windows versions of Pidgin and GIMP). Can we not get this reconsidered?

I also could not agree more. I can't count the number of times I've typed in filenames only to find that I'm searching instead of actually entering a file name. This is a fundamental flaw in GUI logic. If one does a Save As..., the most common next action is to enter the new file name.

Please fix this.

If gdi2k (#11) did not make a valid point, I would like David to tell us why it is invalid. The interest generated here and the obvious UI flaw which is easy to fix makes this an obvious candidate for a papercut. Seeing how David has abstained from commenting on this bug again, and it has acquired significant new evidence, I am overruling his invalidation until he returns to comment once more; at which point it will be completely up to him to decide the validity.

  1. I marked the bug invalid /in the hundredpapercuts project/ -- this does not mean that the current behavior is acceptable or that the proposed improvement isn't good; it simply means that the proposed fix does not meet the definition of a paper cut given at http://wiki.ubuntu.com/PaperCut. Paper cuts should have obvious, non-contentious solutions and this change looks like it could be disruptive. The actual project that this bug occurs in is ultimately responsible for the fix -- hundredpapercuts doesn't decide which bugs are not fixed, so being marked Invalid in hundredpapercuts is no cause for alarm.

  2. I do not think the current behavior is good; I'm not sure why Matthew believes I think it is!

If we remove the proposed tab order change, I think this can be a paper cut. This would mean that the only change of behavior would be moving focus back to the filename entry when navigating with the mouse. Still, the change required to a standard Gtk component could be non-trivial, so someone more familiar with the actual implementation of this solution will have to make the final determination as to whether this can be considered a paper cut.

Cody, is it trivial to move input focus back to the filename entry of the save dialog when navigating via cursor? Would upstream be open to a change like this?

Just to be clear , the gtk+ status change to new was to ensure that the bug does not expire and get closed, eventually. [as the papercut task has been closed]

If anyone wants to do some work on this bug, here's a patch to get you started. This sets the focus to the location entry when you double click the file browser treeview.

I don't have time to look into all the details right now, but if someone here does then I'll be glad to help/mentor you if you want to finish this up.

The file chooser widget runs in different modes, and this patch should probably ensure that it only moves the focus if the chooser is running in certain modes. We also probably also only want this behavior for save dialog operations, not for open dialogs. If I double click in the file browser while I'm trying to open a file, I want to still be able to search in the file browser treeview by typing.

To add some more specifics, the modes you should be looking into are stored in impl->operation_mode and impl->location_mode. The patch should be improved so it checks:

if (event->button == 1 && event->type == GDK_2BUTTON_PRESS)
{
    if ((impl->operation_mode == OPERATION_MODE_SEARCH || /* whatever */) &&
         (impl->location_mode == LOCATION_MODE_PATH_BAR || /* whatever */))
    {
        g_timeout_add (50, (GSourceFunc) location_entry_grab_focus, impl);
    }

   return FALSE;
}

I agree this is a horrible, horrible bug. No one in their right mind names a new file before selecting the directory to save it in!

The obvious solution would be to switch focus back to the Name field after a new folder has been selected. However, another possible solution that (I think) will avoid any breakage to current behaviour would be if the file chooser widget, upon finding no match for the typed filename and the user pressing RETURN (i.e. that filename does not exist), were then to transfer the focus as well as that filename to the Name field.

While that technically would work, for many of us who are expecting the selection when beginning typing that would also be confusing. I don't necessarily notice that the selection box has popped up at the bottom when I'm looking at the name.

One thing that I think would help this bug (for me anyway) would be to differentiate the highlight colour between boxes that have focus and boxes that don't. For example if it were a grey highlight when it did not have focus and a slightly orangish (or whatever for the new theme) tinge for highlighted+focused it would (eventually) be obvious that you don't have it focused.

Though I definitely agree in general that the better fix is simply to revert focus back to the name.

Also, does this qualify for the latest round of papercuts? I assume the reason this was changed to invalid was due to the last round of papercuts finishing, though I'm not entirely familiar with the process.

No, apparently due to the complexity and depth of the issue, it doesn't qualify as a papercut.

Meanwhile Mozilla has fixed the issue in Firefox by simply redesigning the "Save As..." dialog entirely. While I welcome the progress, it's frustrating that this oft-used interface will no longer be standard across all applications on the desktop - OpenOffice used to have its own unique open / close dialogs and it wasn't pretty (although perhaps more functional).

http://www.webupd8.org/2010/07/firefox-40-nightly-gets-new-download.html

Who, where, how do I add my voice to increase the priority of this issue? Or, if it has been fixed, how do I install the fix?

Status changed to 'Confirmed' because the bug affects multiple users.

Adding my name to this list.

1. Choose Save A Copy in Gimp
2. Navigate by mouse to folder where I want to save
3. See that filename is highlighted so it looks like filename box has focus
4. Begin typing
5. Find that my text is appearing to the bottom right of the box.
6. Waves of rage as you take hands off the keyboard, move the mouse and click in filename box.
7. Even more rage then as highlighting is gone, so I have to delete the file name manually

Really, it is these little things that drive you mad, when you are just trying to get through the working day. Argh!

this bug => angry wife

I don't think this aspect has been stated explicitely (although yaztromo hints at it), but my primary annoyance with this is that the save dialog helpfully selects the filename without the extension, making it is easy to type a new name with the right extension. However, when I first navigate to the target folder (which I almost always do first), I end up seeing the selected name right there and knowing that I cannot click there to get focus without losing the selection. This is quite frustrating. Therefore, dropping the selection when changing focus or changing the color of the selection, when the field does not have focus, will not fully solve the problem. However, if tabbing my way there was less painful, I think I might be happy.

Playing a bit around, I found a few workarounds:

1) The thumb button, which I have never used, on my very old Logitech mouse will set the focus without touching the selection. However, not everybody has thumb buttons - particularly on laptops. Scrolling with the mouse wheel in the field does nothing. I guess, if it doesn't have any function already, it could be used as a way to set focus too?

2) Right clicking and selecting copy (as the most neutral option) does the trick too at the cost of replacing what you have in the copy/paste clipboard. Not good, if you were planning to hit Ctrl-C as soon as you get focus with the file name selected. A "focus" option in the context menu would solve this, but I guess, that one is hard to sell.

3) I just discovered that the good old Alt-N for the file name field (at least in my Danish version) still works. The underscore doesn't appear until you press alt, making it hard to discover. I guess that is a design decision - aesthetics? Also it takes around a second for the underscores to appear, which makes it feel quite slow and, IMO, even harder to discover.

Sorry for the spamming. I forgot to mention my last idea: Clicking the label for the field could be a way to set focus to the field. I think it does this on Windows, but correct me if I'm wrong.

I would like to note that this is still/again a problem in 2019 on Ubuntu 19.04. (I didn't notice it on 18.10, but maybe I just missed it.) I agree with pretty much everything that gdi2k wrote above, particularly that the following seemingly simple change would remove a significant annoyance for anyone who occasionally uses the mouse without at all detracting from keyboard-only functionality:

"Reverting focus to the Name field if a folder is double-clicked using the mouse (familiar Windows behaviour, which does not impact keyboard-using advanced users in any way)."

I'm also hit by this daily and think that it should be fixed. Thanks @phusen for the tip of the Alt+N shorcut! But even with the Alt+N shortcut it is confusing that a highlighted field does not have focus. And after Alt+N I still have to click the Save button with the mouse as the Enter key now does not finish the dialog.

The general goal-level requirement from a usability perspective: "It should be easy to use the save dialog both with mouse and keyboard only."

Agreed. yaztromo identified the frustration well. I've been living with this in Mint Cinnamon for years, and still can't seem to get used to it. Thanks for the Alt+N shortcut (works in English/US version). Maybe that'll help me stop cursing at my computer every time I save a file.

Returning the focus to the filename after using the mouse (or touchpad) to navigate into a folder would be ideal. The only reason to use the find is when input is solely from keyboard.

This truly feels like a significant downgrade when coming from any other OS.

This is a very irritating thing, and should be easy to solve. The fix is just changing initial focus!
Hard to understand this has been open for 12 years now.

There's even a risk of data loss by unintentionally overwriting a file when one types, *as it works just fine on all other OS*, the filename to save the file as and hits return... overwriting some other file that just happened to "match" the "filter".

I think I have found the solution:
Set org.gtk.Settings.FileChooser.LocationMode to "filename-entry" in dconf

Or in terminal: gsettings set org.gtk.Settings.FileChooser location-mode filename-entry

Alas, it seems that the devs do not want us to use it :-(
See: https://bugs.launchpad.net/ubuntu/+source/meta-gnome3/+bug/1830979
https://gitlab.gnome.org/GNOME/gtk/-/issues/938

It works for me, but I have to redo it everytime I re-run the program using a save dialog.(*)

I guess we should lobby for gtk to obey org.gtk.Settings.FileChooser.LocationMode. The current default borders to insanity.

(*) I now have this simple script running in background:

#!/bin/bash
# org.gtk.Settings.FileChooser location-mode should be filename-entry
# but it is being reset to path-bar

gsettings set org.gtk.Settings.FileChooser location-mode filename-entry
d=$(date +%s)
while read line; do
    [[ $line =~ filename-entry ]] && continue
    gsettings set org.gtk.Settings.FileChooser location-mode filename-entry
    od="$d"
    d=$(date +%s)
    echo "location-mode reset at $(date +%Y-%m-%d.%T), after $((d - od)) s"
done < <(gsettings monitor org.gtk.Settings.FileChooser location-mode)

Le samedi 20 novembre 2021 à 14:12 +0000, colas a écrit :
> I think I have found the solution:
> Set org.gtk.Settings.FileChooser.LocationMode to "filename-entry"

Yes! Now it must be made the default value in Debian!

Just adding my support to those rallying for change on this issue.

I tried colas' script in the background, but whilst it does report that it's resetting location-mode, it doesn't seem to be solving the problem for me (on Jammy Jellyfish).

I also noticed there's another schema/key,
org.gtk.gtk4.Settings.FileChooser location-mode
so I tried running two copies of the script to cover both keys, but that's still not giving me any joy. Perhaps the issue is that I'm using awesomewm, but it's the same Save As dialog I'd have thought.

Either way - this is far and away the worst feature of Ubuntu for me - it bothers me every time I use it. My personal feeling is that all other cosmetic development on Ubuntu should be stopped until this issue - that must be used thousands - maybe millions? of times a day - is fixed.

Thanks to all those above who've pushed for this.

The file-chooser dialog as descripted in comment No. 43 bothers me since I updated to Jammy.

It's not the state of art and workflow. Glad I found this place to urgently beg for a change. I will try the solutions offered in comments 41 and 42.

Is Cody actively working on this? If not, should he be unassigned?