GNOME Bugzilla – Bug 773333
The file chooser's built-in search frequently misses results
Last modified: 2018-05-02 17:41:16 UTC
I don't have a complete understanding of what the bug is, but the file chooser's built-in search seems to fail to show complete results on a regular basis. As a trivial reproducer, go to "Save as..." in any application, click "Home", and type "music". You'll see the Music folder. Then hit backspace five times, pausing a bit between each one. You'll see the full contents of Home. Now type "music" again and hold down backspace until the search bar is blank. You'll see a very small subset of the full contents. (As an aside: shouldn't hitting backspace when the search box is empty dismiss the search box?)
(In reply to Andy Lutomirski from comment #0) > As a trivial reproducer, go to "Save as..." in any application, click > "Home", and type "music". You'll see the Music folder. Then hit backspace > five times, pausing a bit between each one. You'll see the full contents of > Home. Now type "music" again and hold down backspace until the search bar > is blank. You'll see a very small subset of the full contents. the FileChooser spawns threads to enumerate each new directory browsed into. Maybe they give up if called in rapid succession, or something like that. It certainly looks like the search just gets cancelled if restarted quickly. > (As an aside: shouldn't hitting backspace when the search box is empty > dismiss the search box?) Hmm, not necessarily. That would seem to punish users who hold down backspace and don't stop quite quickly enough. Unless some hacking was added to detect isolated presses with no text after a long enough pause, or something, but pressing Esc is easy enough. ;)
(In reply to djb from comment #1) > the FileChooser spawns threads to enumerate each new directory browsed into. ...I should really finish writing messages before posting them. This applies to searches too, so the rest holds. We can observe this in either case with gdb.
(In reply to djb from comment #1) > (In reply to Andy Lutomirski from comment #0) > > > As a trivial reproducer, go to "Save as..." in any application, click > > "Home", and type "music". You'll see the Music folder. Then hit backspace > > five times, pausing a bit between each one. You'll see the full contents of > > Home. Now type "music" again and hold down backspace until the search bar > > is blank. You'll see a very small subset of the full contents. > > the FileChooser spawns threads to enumerate each new directory browsed into. > Maybe they give up if called in rapid succession, or something like that. It > certainly looks like the search just gets cancelled if restarted quickly. A bug like that could easily explain the weird results I've been seeing. > > > (As an aside: shouldn't hitting backspace when the search box is empty > > dismiss the search box?) > > Hmm, not necessarily. That would seem to punish users who hold down > backspace and don't stop quite quickly enough. Unless some hacking was added > to detect isolated presses with no text after a long enough pause, or > something, but pressing Esc is easy enough. ;) How so? If you hit backspace too many times and start typing again, the search bar will reappear.
(In reply to Andy Lutomirski from comment #3) > > A bug like that could easily explain the weird results I've been seeing. Yeah, this is an interesting one, as it seems to break the reliability of search results, since the user might not realise they're missing things... and even if they do, then the only way to 'fix' it is to - slowly! - change the search, then change back. Correct me if I'm wrong - Nautilus doesn't seem to share this issue, right? > How so? If you hit backspace too many times and start typing again, the > search bar will reappear. Indeed, never mind. I should also be fully awake before writing posts. :D
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/692.