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

Bug #1878076 reported by fcole90
58
This bug affects 9 people
Affects Status Importance Assigned to Milestone
GTK+
New
Unknown
gtk+3.0 (Ubuntu)
Triaged
Low
Unassigned
gtk4 (Ubuntu)
Triaged
Low
Unassigned

Bug Description

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

Revision history for this message
fcole90 (fcole90) wrote :
Revision history for this message
Sebastien Bacher (seb128) wrote :

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)

Changed in gtk+3.0 (Ubuntu):
importance: Undecided → Low
status: New → Triaged
Changed in gtk:
status: Unknown → New
Revision history for this message
fcole90 (fcole90) wrote :

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.

Revision history for this message
fcole90 (fcole90) wrote :

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

Revision history for this message
fcole90 (fcole90) wrote :

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

Revision history for this message
Steve Dodd (anarchetic) wrote :

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.

Revision history for this message
Christian Lampe (lampe2020) wrote (last edit ):

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.

Revision history for this message
Tomohiro Hashizume (hashi0527) wrote :

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.

tags: added: jammy
Revision history for this message
Daniel van Vugt (vanvugt) wrote :
Changed in gtk4 (Ubuntu):
status: New → Triaged
importance: Undecided → Low
Revision history for this message
John Ullrey (jullrey) wrote :

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

Revision history for this message
Jason Alavaliant (alavaliant-r) wrote :

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.

Revision history for this message
Jason Alavaliant (alavaliant-r) wrote :

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

Revision history for this message
Daniel van Vugt (vanvugt) wrote :
Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

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.]

tags: added: patch
Revision history for this message
Luca Bacci (lb90) wrote :

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?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.