desktop-packages team mailing list archive

[Launchpad Bug Tracker <1477322@xxxxxxxxxxxxxxxxxx>]

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 <iain@xxxxxxxxxxxxxxxxxxx>  Wed, 07 Oct 2015 16:40:08
+0100

** Changed in: nautilus (Ubuntu Wily)
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to nautilus in Ubuntu.
https://bugs.launchpad.net/bugs/1477322

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

Status in nautilus package in Ubuntu:
  Fix Released
Status in nautilus source package in Wily:
  Fix Released

Bug description:
  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)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1477322/+subscriptions