Nautilus searches All Files when it should search Home

[Colin Law]

To replicate, on Raring

Open Nautilus on the users Home folder.
Click in the right hand pane
Type, for example, the word down
Nautilus shows the results of searching for 'down' in All Files even though Home is selected to the right of the search window. It should only show matching files in the current folder. Clicking on All Files and Home refreshes the view but still all matching files are shown.

I believe that this is a regression introduced recently as I have been using Raring Alpha for some time and I have not noticed the problem previously.

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: nautilus 1:3.6.3-0ubuntu16
ProcVersionSignature: Ubuntu 3.8.0-19.29-generic 3.8.8
Uname: Linux 3.8.0-19-generic i686
ApportVersion: 2.9.2-0ubuntu8
Architecture: i386
Date: Mon Apr 29 21:25:40 2013
GsettingsChanges:
 b'org.gnome.nautilus.window-state' b'geometry' b"'1136x520+1427+249'"
 b'org.gnome.nautilus.window-state' b'sidebar-width' b'213'
InstallationDate: Installed on 2012-08-01 (271 days ago)
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Alpha i386 (20120730.1)
MarkForUpload: True
SourcePackage: nautilus
UpgradeStatus: No upgrade log present (probably fresh install)

[Christian González (droetker)]

"It should only show matching files in the current folder."
This is not correct IMHO, as it should show all files that match the search pattern in the current folder and folders BELOW that. Can you confirm that?

[Colin Law (colin-law)]

Christian, yes I see you are correct, it shows files in the current folder and below. I find that very confusing, but I suppose it is probably as designed.

[TBeholder (turbobeholder)]

Yes, quick-search feature and Ctrl-F do the same. This
1) makes them reundant.
2) makes quick-search mostly unusable for the original purpose - that is, quick selection of a file without having to scroll through long lists. Suppose the user wants to find ".profile" in $HOME.
Expected behaviour: type ".p" and it would be 2-nd or 3-rd file after selected.
What happens instead: the first pressed key nearly freezes nautilus as it tries to dig through the whole $HOME/* tree - then it may eventually show every ".*" file down there or may freeze completely. Until then, it does both intense disk seeking and CPU consumption. The problem: even in best-case scenario, scrolling a long list is faster by many orders of magnitude in any place with big subtree, like $HOME or /usr/share. Meaning quick-search is almost useless for quick searching.
Both points mean it's a bug.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.