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 764668 - File gets selected that shouldn't get selected
File gets selected that shouldn't get selected
Status: RESOLVED NOTGNOME
Product: gtk+
Classification: Platform
Component: Widget: GtkFileChooser
3.18.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2016-04-06 08:10 UTC by sworddragon2
Modified: 2017-09-19 15:40 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description sworddragon2 2016-04-06 08:10:13 UTC
If I'm navigating with the FileChooser to a directory and then pressing at first a key which wouldn't cause a match for any file in this directory (for example in many cases by pressing "y") always the first file gets selected.
Comment 1 Daniel Boles 2017-09-18 17:29:23 UTC
Can you give more precise steps?

And what do you consider "would cause a match"? On the 1st character, or anywhere in the name?

When I press a character that doesn't occur in any filename, the search starts, and no results are returned, so there is no file there to be selected.
Comment 2 sworddragon2 2017-09-18 23:34:09 UTC
On retesting this with GTK+ 3.22.19 I'm seeing the same behavior as you except that the first file in the FileChooser keeps a dashed line (which is the correct behavior?) so I can't reproduce the issue from the startpost anymore.

If no questions are open this ticket can be closed.
Comment 3 Daniel Boles 2017-09-18 23:40:34 UTC
Thanks for the update!

(In reply to sworddragon2 from comment #2)
> On retesting this with GTK+ 3.22.19 I'm seeing the same behavior as you
> except that the first file in the FileChooser keeps a dashed line (which is
> the correct behavior?)

Is this what you mean?

If there *is* a match for the typed character, focus (indicated by dashed outline), focus goes to the 1st matching file, away from the search entry - although typing another character to search (of course not including Space... Bug 765551) will restart the search-and-possibly-select-first-file cycle. (That almost seems like a mini version of Bug 770941 in how intuitive it is)

I'm happy to close it if you think the original issue is resolved/obsolete.
Comment 4 Daniel Boles 2017-09-18 23:41:37 UTC
> typing another character to search (of course not including
> Space... Bug 765551) will restart the search-and-possibly-select-first-file
> cycle.

oops: replace "select" with 'focus' (i.e. it does not choose that file).
Comment 5 sworddragon2 2017-09-19 00:15:28 UTC
If I'm entering a directory with the FileChooser always the first file has a blue background but no dashed line. Typing a single character that causes nothing to match results that the first file looses its blue background but it gets a dashed line instead.
Comment 6 Daniel Boles 2017-09-19 00:23:38 UTC
Again, if it were really the case that nothing matched, then there would be no files shown in the search results to have backgrounds or outlines or not... :)

What I see when searching and getting matches is that some file - often, but seemingly not always the 1st, gets a focus outline but not blue background, until e.g. I use cursor Down to explicitly focus the file list, then it goes blue.

Are you perhaps running a Ubuntu variant with their (rather erratic) patch that restores typeahead find in the file list's TreeView?

It's hard to tell what the problem is, or whether either of us really consider it to be a problem!
Comment 7 sworddragon2 2017-09-19 00:29:28 UTC
Yes, I'm using Ubuntu. I have no idea if the issue I'm seeing is an issue at all and don't remember if it is maybe the issue I described in the startpost.
Comment 8 Daniel Boles 2017-09-19 00:38:34 UTC
so, this,

(In reply to sworddragon2 from comment #5)
> If I'm entering a directory with the FileChooser always the first file has a
> blue background but no dashed line. Typing a single character that causes
> nothing to match results that the first file looses its blue background but
> it gets a dashed line instead.

refers to typing where: in the window's top search entry with magnifying glass icon, or in the (Ubuntu-specific) treeview's (I think) bottom-right type-ahead entry?

because getting no match in the former would hide the files, so you wouldn't have any focus outline or background to speak about. So I guess you mean the latter?


If you're still not sure how to explain it - or I just can't understand :) , are you able to post a video?
Comment 9 sworddragon2 2017-09-19 00:50:34 UTC
(In reply to Daniel Boles from comment #8)
> refers to typing where: in the window's top search entry with magnifying
> glass icon, or in the (Ubuntu-specific) treeview's (I think) bottom-right
> type-ahead entry?

I type immediately after entering a directory (which I do with a double click). This causes a search on the bottom right to appear (it appears over the file type dropdown). I also do not see a top search entry with a magnifying glass. In my current tests the GTKFileChooser is called via SciTE's Open dialog.
Comment 10 Daniel Boles 2017-09-19 01:01:28 UTC
Right, yeah. In that case, your click means the treeview has focus, and Ubuntu's patch means it gets input for its type-ahead search. Thus, the FCW doesn't get the key and can't open its search (but it will if e.g. the PlacesSidebar or some other accessory widget has focus).

I don't think there's much we can do about this in GTK+, as it depends on a downstream patch restoring behaviour removed from upstream quite long ago. I'd suggest filing it with Ubuntu, if you decide it seems buggy to you. Maybe they'll have a fix on their side (or suggest something innocuous that can help on ours).