Select-by-typing select hidden files even if they are not shown

[teo1978]

I was going to report this upstream, but then I remembered that type-ahead selection of files was removed by retarted upstream Nautilus maintainers, and it has been patched back by Ubuntu as per https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1164016

So:

Steps to reproduce:

1) Have a folder with these files:

  aaa.txt
  aaa.txt~ (hidden)
  aab.txt~ (hidden)
  aac.txt

2) Open the folder in Nautilus; make sure that the "show hidden files" option is NOT enabled

 => so you only see aaa.txt and aac.txt

3) Type: "aa"

4) Hit the down arrow key several times.

Expected behavior:
* Since hidden files are not being shown, they should not be selectable by type-ahead. Hence,
- after typing "aa", aaa.txt should be selected
- at the first keystroke on the down arrow, aac.txt should be selected

Observed behavior:
- After typing "aa", aaa.txt is selected, as expected
- At the first keystroke on the down arrow, no file seems to be selected. aaa.txt is no longer highlighted but aac.txt isn't either. Under the hood, I guess the aaa.txt~ file is "somehow selected" (but if you hit Enter nothing happens, thank god)
- At the second keystroke, still nothing seems to change: still no file apparently selected. But under the hood, aab.txt~ is probably "somehow selected"
- At the third keystroke, finally aac.txt is selected, proving that Nautilus is somehow selecting files even if they are hidden.

Behaving like a file is selected (in that the previous selected one is unselected and that you can skip to the next one) while it is not even visible is INCONSISTENT.

The most reasonable expected behavior is to select and loop through only visible files, so, if hidden files aren't being shown, only non-hidden files must be considered, while if hidden files are being shown, then they must be considered.

Another sensible behavior could be to make the hidden files that match the typed string become visible, and highlight them when they are selected, but that would eventually lead to counterintuitive behavior and design issues (what do you do when the type-ahead box disappear? turn back the hidden files to invisible?)

== ANOTHER EXAMPLE ==

Say you have, in a folder:
  aaa.txt~ (hidden)
  aab.txt

You type "aa"

Expected: aab.txt should be highlighted and selected

Observed: nothing is highlighted, which is exactly the same that would happen if no file matching the typed string existed. So you may even think the file doesn't exist (if you don't look carefully enough, which usually you don't want to, because that is why you use type-ahead in the first place), or you see it right in front of your eyes and you say "why the heck isn't it found??". Only if you think about using the arrow keys you will realize that the file you're looking for actually exists.

Which means that TYPE-AHEAD IS BASICALLY UNRELIABLE: you type something, you see nothing selected, and that's no guarantee that no matching file exists, until you use up/down arrow keys. (actually, you will never be sure: what if there were hundreds of hidden files starting with the typed string? Unlikely but possible)

The whole design of the type-ahead find thingie (which is a very useful, vital feature) is actually shitty. It lacks at least one of two things: either
1) showing the number of matches found
or
2) changing the color of the typed text or its background when no match is found

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: nautilus 1:3.10.1-0ubuntu9.7
ProcVersionSignature: Ubuntu 3.13.0-55.94-generic 3.13.11-ckt20
Uname: Linux 3.13.0-55-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.11
Architecture: amd64
CurrentDesktop: Unity
Date: Wed Jul 22 23:29:18 2015
GsettingsChanges:
 b'org.gnome.nautilus.list-view' b'use-tree-view' b'true'
 b'org.gnome.nautilus.list-view' b'default-column-order' b"['name', 'size', 'type', 'date_modified', 'date_accessed', 'owner', 'group', 'permissions', 'mime_type', 'where']"
InstallationDate: Installed on 2013-10-11 (649 days ago)
InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
SourcePackage: nautilus
UpgradeStatus: Upgraded to trusty on 2014-05-24 (424 days ago)

[teo1978 (teo8976)]

Please for god's sake don't underestimate the importance of this bug. I would hate to see this rated as "low" or even "medium".

Please read the second use case example carefully.

This fulfills at least the criteria for "high":
- "has a severe* impact on a small portion of Ubuntu users (estimated)"
Checking for existence of a file and getting a false negative is definitely a severe impact

- Has a moderate impact on a large portion of Ubuntu users (estimated)
I think users who use type-ahead at all are a large portion (large enough that Ubuntu decided to reintroduce a feature that had been retardedly removed upstream), and the impact is at least moderate in common use cases

And probably:
- "Renders essential features or functionality of the application or dependencies broken or ineffective"
It might be questioned whether type-ahead is an "essential feature" of Nautilus, but the bug definitely renders it broken *and* ineffective.

[Sebastien Bacher (seb128)]

Thanks, indeed that should be fixed this cycle or before the next lts at least

[Launchpad Janitor (janitor)]

This bug was fixed in the package nautilus - 1:3.14.2-0ubuntu11

---------------
nautilus (1:3.14.2-0ubuntu11) wily; urgency=medium

  * debian/patches/interactive_search.patch:
    - Don't match hidden files if we aren't displaying them. (LP: #1477322).
    - Remove some annoying stray trailing spaces.

 -- Iain Lane <email address hidden> Wed, 07 Oct 2015 16:40:08 +0100

[Amr Ibrahim (amribrahim1987)]

This bug affects Trusty. Please backport the fix.