GTK save-dialogs input-focus moves from filename to file search if a folder is selected

[fcole90]

This bug is also reported on GNOME's GTK GitLab: https://gitlab.gnome.org/GNOME/gtk/issues/326

## Steps to reproduce
 1. Open any GTK app which uses save dialogs (e.g. gedit)
 2. Press save
 3. A save dialog appears and the filename is highlighted (if typing at this point you edit the file name)
 4. Click on a different folder (e.g. Downloads)
 5. The filename is still highlighted, hinting that the focus is still there
 6. Type and find yourself searching for a file in the selected folder

-- Current behavior --
The higlighting (on the file name) hints a focus which is not the actual input focus, and the actual input focus (the search bar) is hidden until one starts to type, which I think to be confusing and unexpected. Also, clicking back on the highlighted filename you lose the highlighting, so you have to highlight again some already highlighted text; I think this to be confusing and counterintuitive.

-- Expected outcome --
Highlighting and focus need to match. If they don't that's a UX bug, and there are several options to solve it, some examples:
- keep highlighting as is and keep focus on the filename, this whould require finding a different path for file search (I think this is the most productive option, because I assume a user wants to change the folder and eventually rename or name the file, which I consider more likely than a user wanting to search for a file within a save-file dialog);
- keep filesearch as is, but show its bar before typing begins, and remove any highlighting from filename.

For reference, Windows 10's native save-file dialogs disables the highlighting when clicking on a different folder. Typing does nothing at that point.

Tested on gedit 3.36.1 on Ubuntu 20.04.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: libgtk-3-0 3.24.18-1ubuntu1
ProcVersionSignature: Ubuntu 5.4.0-29.33-generic 5.4.30
Uname: Linux 5.4.0-29-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.11-0ubuntu27
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: GNOME
Date: Mon May 11 21:53:37 2020
InstallationDate: Installed on 2020-04-03 (37 days ago)
InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Beta amd64 (20200401)
SourcePackage: gtk+3.0
UpgradeStatus: No upgrade log present (probably fresh install)
mtime.conffile..etc.apport.crashdb.conf: 2020-05-04T10:26:46.106768

[Sebastien Bacher (seb128)]

Thanks, there is no real need to report known upstream issue downstream though (unless it's an important issue you believe Ubuntu should prioritize or a patch is available which should be considered for a backport)

[fcole90 (fcole90)]

Hi, I think this is a disappointing papercut and a long lasting issue. I'm discussing with gtk devs if this behaviour is intended or is a bug.

[fcole90 (fcole90)]

The bug appears to be fixed for me in the current stable version of Ubuntu 20.04 with all updates applied.

Can someone double check that the following steps work correctly:
1. Open "save" menu from some gnome app (e.g. gedit)
2. Start typing -> expected to type on filename
3. Change folder from left panel
4. Start typing again -> expected to type on filename

[fcole90 (fcole90)]

It appears the bug is still around when changing folder from the main view, rather than using the sidebar

[Steve Dodd (anarchetic)]

The bug has been periodically tripping me up for years, but recently I discovered that it has basically stopped my elderly uncle from using Libreoffice (which defaults to GTK file picker on Xubuntu at least) on bionic. Priority really needs to be higher, at least if the intent is for Ubuntu to be usable by non-power users. To be honest, I felt actually embarrassed when I realized that the standard process for saving a file in a non-default folder ("Save As..", click folder, type filename) is broken. Particularly as, as mentioned above, the highlight in the text entry is misleading.

At the risk of sounding like I'm sulking, going to have to seriously consider moving my - and all my family's - machines to a non-gtk based desktop environment if upstream's attitude to a significant usability bug like this is to just ignore it for years. An ubuntu-specific patch would at least reduce the urgency somewhat! I'd settle for an option (gtk.ini or whatever) to disable the search functionality if that would help.

[Christian Lampe (lampe2020)]

I have the problem still in Ubuntu Unity 22.04. (it just manifests itself a little differently)

If I actively place the focus in the file name field by clicking there ( I need to click twice, otherwise only the focus indicator is moved!) I can type one letter and at the same time the focus jumps automatically to the search bar. When I actively place the focus back into the file name field the cycle repeats.
I have to click in the file name field twice for every single letter I want to type in the file name field, sometimes more often. You can hear that in the attached video.

I think Firefox does also use that dialog, at least it shows similar behaviour.
If you leave the original file name and click on "Spara" ("Save") then there's a chance that the file will actually be saved as that.

Workaround: Just type in the search bar and copy over to the filename bar. Maybe even with middle-click if the previous clipboard content is still neded.

[Tomohiro Hashizume (hashi0527)]

I would just like to point out that this bug persists on

Ubuntu 22.04 on unity desktop.
kernel: 5.15.0-58-generic

The folder swapping trick doesn't work. Only way to change the file name is to copy and paste the filename written elsewhere.

[Daniel van Vugt (vanvugt)]

A draft fix for GTK4 is here:
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4945

[John Ullrey (jullrey)]

I just encountered this bug for the first time today, and it's super annoying!

$ cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.2 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.2 LTS (Jammy Jellyfish)"

$ uname -a
Linux john-desktop 5.15.0-67-generic #74-Ubuntu SMP Wed Feb 22 14:14:39 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

$ echo $XDG_CURRENT_DESKTOP
Unity:Unity7:ubuntu

[Jason Alavaliant (alavaliant-r)]

On u22 I ran into this problem with programs using gtk4 file dialogs.
Rebuilding the gtk4 packages (libgtk-4-1 etc) with the https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4714 patch fixed it for me.

[Jason Alavaliant (alavaliant-r)]

Sorry to clarify my last post, By u22 I meant Ubuntu 22.04

[Daniel van Vugt (vanvugt)]

Interesting because the upstream bug has different fixes proposed at the moment...

https://gitlab.gnome.org/GNOME/gtk/-/issues/326
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4945
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4960

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "Patch to libgtk-4 that fixes the problem for gtk4 file dialogs in my testing" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Luca Bacci (lb90)]

Hi everyone! This issue is fixed in https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4674, maybe it could be backported to Ubuntu 22.04?