After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 764858 - When saving file, focus is sometimes in locate file box instead of filename box
When saving file, focus is sometimes in locate file box instead of filename box
Status: RESOLVED DUPLICATE of bug 770941
Product: gtk+
Classification: Platform
Component: Widget: GtkFileChooser
2.24.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2016-04-10 18:44 UTC by deutrino
Modified: 2017-09-19 00:04 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description deutrino 2016-04-10 18:44:05 UTC
Apologies in advance for not including instructions for reproducing this, but it's fairly hard to reproduce. I want to make the bug as a placeholder / search engine bait in case anyone else is experiencing it, and will come back and update it when I can figure out how to reproduce it.

WHAT ACTUALLY HAPPENS

1. Enter File > Save or File > Save As dialog. I've seen this in GIMP and (I believe) gedit.
2. Start typing a file name.
3. Focus is in a small box in the lower right which is intended to skip to a file in the chooser based on the text the user is typing.
4. The user must click back into the file name entry textfield to actually enter the file name.

WHAT I EXPECT TO HAPPEN

1. Enter File > Save or File > Save As dialog
2. The focus should always be in the file name entry textfield.

REPRODUCIBILITY

Difficult. I am not sure how after experiencing this dozens of times, so I will keep a much better eye out in the future.

OTHER INFORMATION

I am filing this against GTK+ version 2 because both GIMP and gedit depend on GTK+ 2 on my system.

I don't believe this is caused by a spurious Tab or other keyboard shortcut, as I usually use the mouse to enter save dialogs.

This is Linux Mint 17.3, amd64.

Installed packages which I believe are relevant:

* libgtk2.0-0 version 2.24.23-0ubuntu1.4
* libgtk-3-0 version 3.10.8~8+qiana
Comment 1 Daniel Boles 2017-09-05 18:50:13 UTC
(In reply to GoMo from comment #0)
> Apologies in advance for not including instructions for reproducing this,
> but it's fairly hard to reproduce. I want to make the bug as a placeholder /
> search engine bait in case anyone else is experiencing it, and will come
> back and update it when I can figure out how to reproduce it.

Since no one else managed, did you ever have any luck with that?

I've not been able to reproduce the quoted issue.

If anyone else sees this and can make it happen, please do post the info too.
Comment 2 deutrino 2017-09-07 21:03:35 UTC
It's still happening for me on occasion just like always, I'll try to develop steps to reproduce in the next week or two... stuck it in my calendar as a reminder
Comment 3 deutrino 2017-09-18 15:47:08 UTC
I've found a situation that will do it, it only happens when browsing to a new save location other than the default.

I've reproduced this in GIMP (where it bit me this morning) and my text editor, on Linux Mint 18.2 Sonya (cinnamon 3.4.6+sonya, libgtk2.0-0 2.24.30-1ubuntu1.16.04.2).

Steps to reproduce:

1. File > Save As, or with a new file, File > Save.
2. Navigate to a new directory in which to save, by clicking at some point in directories in the main file browser pane. Clicking only in the Places pane reveals a *different* pathological behavior which is described below (see "bonus round").
3. Note that the existing file name is highlighted in the Name field. Start typing a new file name.

What actually happens:

An unlabeled control appears below the bottom right corner of the file browser pane and steals focus. Typing in this box jumps to and highlights files/directories in the browser pane if the start of the strings match.

What I expect to happen:

Text entry should start overwriting the highlighted file name in the Name field, as it does if I do not navigate to a new directory. This may be debatable, but the behavior does break my expectations because the file name text is highlighted.

Bonus round:

If you change to a different save directory by only clicking in the Places pane and then start typing, a *different* control (with a magnifying glass label) pops up at the *top* of the file browser pane, and text starts appearing there... then after a brief period of time, the unlabeled control appears at the lower right corner and steals focus from the magnifying glass control!

Interpretation:

It seems that the conditions for the unlabeled control popping up and taking focus, are over-broad. Or perhaps that the control should not exist, and instead the labeled magnifying box control should pop up in its place, since its function is more immediately obvious.
Comment 4 Daniel Boles 2017-09-18 15:56:58 UTC
(In reply to GoMo from comment #3)
> 2. Navigate to a new directory in which to save, by clicking at some point
> in directories in the main file browser pane. Clicking only in the Places
> pane reveals a *different* pathological behavior which is described below
> (see "bonus round").
> 3. Note that the existing file name is highlighted in the Name field. Start
> typing a new file name.
> 
> What actually happens:
> 
> An unlabeled control appears below the bottom right corner of the file
> browser pane and steals focus.

Right, so that's probably Bug 770941, i.e. the file list takes focus on click, but the entry still looks (at least to some extent) as though it has the focus.

I haven't checked how that looks in GTK+ 2, but in 3, you can tell *something* has changed because the outline of the entry is no longer highlighted, even though the selection keeps the same colour.

It's basically the latter that is the contentious issue in GTK+ 3; people expect it to have a selected-but-not-focussed colour, and the disappearing blue outline around the entry isn't noticed enough.
Comment 5 Daniel Boles 2017-09-18 16:00:35 UTC
The other alternative is for the file list or sidebar not to take focus on click, but doing that would just rile up a different group of users, for other reasons. IMO focussing on click is valid, but the theme shouldn't be as misleading as it is. I have no influence on the design, though, which was specifically decided on.
Comment 6 deutrino 2017-09-18 16:33:13 UTC
Couldn't this be solved by managing user expectations by de-highlighting the file name?
Comment 7 Daniel Boles 2017-09-18 17:12:26 UTC
That question is precisely the point of Bug 770941, which is why I linked you there.

If you think that would be a solution, then let's mark this one as a dupe of it.

Otherwise, I could try to dig up the other bug about focus-on-click - but I really doubt that is anywhere near as likely to be the winning solution (if any).
Comment 8 deutrino 2017-09-18 22:54:37 UTC
Having read it now, I would say that this bug is a dupe of #770941, yeah.

*** This bug has been marked as a duplicate of bug 770941 ***