It's not a bug; the removal of the type-ahead search was very much intentional:

commit 8f9c8120b9d8a4cfa9ed1777da37f7a2d618a3a6
Author: Matthias Clasen <mclasen@redhat.com>
Date:   Sat Jan 24 08:04:36 2015 -0500

    file chooser: Turn off typeahead search
    
    It is the third kind of navigation entry in the file chooser after
    the location entry and search, and it interacts badly with both
    of the others.

commit 71bd1c7e2c5252b5103bf029e437787e0a002951
Author: Matthias Clasen <mclasen@redhat.com>
Date:   Tue Mar 3 18:02:09 2015 -0500

    file chooser: Really stop typeahead search popups
    
    GtkTreeView is a bad widget and constantly resets the search-column
    behind our back. We need to re-unset it every time a model is set :-(

The idea is to make sure that the tab completion entry gets activated as soon as you start typing in the file chooser, and that the search mode of the file chooser widget is fast and returns appropriate results.

It is debatable whether we should do type ahead or whether we should do search for consistency like nautilus, but the point is that right now you press ctrl+O in gedit, start typing and *nothing* happens.


FWIW this is becoming a constant complaint from all the gedit user who update to the new version

IMHO whatever the design is, it needs some kind of feedback that nothing was found (nautilus doesn't neither, I have a patch for it, but there is clearer since you are in a special view at least). Doing nothing at all looks strange.

(In reply to Carlos Soriano from comment #3)
> IMHO whatever the design is, it needs some kind of feedback that nothing was
> found (nautilus doesn't neither, I have a patch for it, but there is clearer
> since you are in a special view at least). Doing nothing at all looks
> strange.

To make this clear I don't get *any* feedback even if I type chars that are the beginning of files I want to open. So I get no functionality at all. This is very confusing IMO. The whole GNOME experience offers type to search and after some time you rreally appreciate it and then comes this dialog and just nothing happens while you expect it to behave the same as the rest of GNOME.

(IIRC this gets solved with the mockups for a completely new filechooser but this seems far away.)

(In reply to Lasse Schuirmann from comment #4)
> (In reply to Carlos Soriano from comment #3)
> > IMHO whatever the design is, it needs some kind of feedback that nothing was
> > found (nautilus doesn't neither, I have a patch for it, but there is clearer
> > since you are in a special view at least). Doing nothing at all looks
> > strange.
> 
> To make this clear I don't get *any* feedback even if I type chars that are
> the beginning of files I want to open. So I get no functionality at all.
> This is very confusing IMO. The whole GNOME experience offers type to search
> and after some time you rreally appreciate it and then comes this dialog and
> just nothing happens while you expect it to behave the same as the rest of
> GNOME.
> 
> (IIRC this gets solved with the mockups for a completely new filechooser but
> this seems far away.)

Oh ok, that looks like a bug, instead of what I'm saying that is more a request.

In master, you _can_ type and get the completion popup to appear. Unfortunately, it only works if focus is on the right place, which can be frustrating. More work needed, and any help is welcome. I'm only doing filechooser fixes because nobody else is, not like its my job...

Latest batch of changes in the FileChooser for 3.17/3.18:

 * typing will start the completion popup (as Matthias wrote in comment #6)
 * Alt+S will get you in search mode
  * Search will run both the indexed and the file tree walk results at the same time (bug 744205)
  * Search will show results for the current directory first (744205)
  * Search will work on remote volumes (bug 746916)

Also, as Carlos asked in comment #3, if no results are found the file chooser will explicitly say that.

I tried the latest gtk+ 3.17.3

It is true that ctrl+o + typing starts now does *something* (in 3.16.x nothing happens). A text entry pops up which perfoms some (poor) kind of tab completion. This seems to work only for the first folder, though. After entering it (say I typed "de", then return to enter "dev") the focus goes to some breadcrumb button and no kind of type-to-find works.

Most annoying is that if multiple folders match what's typed that doesn't complete anything, and therefore pressing return does nothing. And worse, pressing arrow down focuses the file list instead of going through the completion candidates (going down to focus the file list is very convinient on normal situations but it makes it impossible to chose between tab completion candiates here). With type-ahead the first match would be selected and then I could use the arrow keys to go through the other matches.

Regardless of bugs (it's not working usefully/correctly right now), I must say that the tab completion this is nowhere near as useful as type-ahead search which is one of the most convenient methods to browse for something to me. I do know my file layout, and I know exactly how many chars and how many times I need to press down afterwards to select my folder of interest. I extensively use type-ahead in the file browser (nemo) and I totally want this in the file chooser dialog as well.

Why do you break so many people's use case without giving any option to restore the old behavior? I can understand you want to be consistent with nautilus[1] but I don't use nautilus and I don't care about. But I really care about type-ahead find being available in the file chooser, it's crucial to me.

Wouldn't it be possible to restore the old behavior through some GSetting schema? Would you accept a patch that implements this?


[1]: Which seems weird given nautilus is a GTK user, not the other way around, and a whole lot of people *disliked* that particular nautilus change too)

Things are improved for 3.17.4

This issue is NOT "RESOLVED FIXED" as the status claims. Not by a long shot. It's been a year, and I can't believe the Gnome team refuses to make this an option.

The behaviour in the Gtk2 FileChooser is perfect. I know my file structure, and in Gtk2 programs, I can navigate through my files in a fraction of a second by typing the first couple of letters of each folder, and hitting enter.

The Gtk3 file search is NOT equivalent. It is NOT an alternative, and it is NOT good enough.

In the Gtk3 FileChooser, I have to type what I am looking for, wait a second for it to finish loading, and see that it has cluttered my screen with hundreds of entries that match in subfoders of subfolders of subfolders, such that I can't find the files in the directory I'm in.

If I decide I didn't want to search, and backspace out my search term, I am left at a screen that lists ALL FILES in ALL SUBDIRECTORIES. Instead of being brought back to the directory I was searching in.

I honestly don't see how this behaviour benefits anyone. I don't disagree that there should be a search, but it should most definitely not be the default behaviour. We should have either a search bar at the top, or a button to open a search dialog.

At the very least, typeahead should be an option for the user to enable without having to modify the source code and recompile Gtk.

Hello,
+1 for NOT FIXED. This behavior is driving me nuts. I finally took the time to search the web to see which option I have accidently enabled to get such a weird behavior. It is a common UI paradigm that you can type a character while the cursor is in a list and the entry with starting with the typed character is being highlighted and it's marked.

Under no circumstances shoud the list change and even list stuff outside this folder. This messes with the brain as you have to completely rescan the screen to find again what you're actually look for. The current behavior makes it even worse.

Say, I want to open to upload a picture to my favorite social media site. Firefox opens the file dialog in my home directory. I type "P", because I'm too lazy to scroll 3 pages and search for the Pictures folder. This was the perfect.

Now I hit P and P* from my 200GB home directory is listed. And even if I see "Pictures" for a split second, I can't click on it because it jumps around until the search has finished.

Silently removing the previous behavior is a regression. An severe one. Design decisions are one thing, but they should support the user, not hinder them.

Please tell me how I can accomplish my task. I have a mixture of files and folders in my home directory. Finding Pictures with just hitting P could be accomplished in less than half a second and without touching the mouse. 

How to do the same with the new behavior? I will happily accept any help.

Best Regards,
Stefan

Everything Daniel and Stefan said.  Please allow the GTK2 behaviour at least as an option configurable in dconf or similar.

If this is something the gnome folks are unwilling to do, what do the rest of you think of forking the project and starting something parallel?

Jonathan: A patch was submitted more than a year ago now to re-add this as an option, but the GNOME developers seem to be unwilling to accept it, claiming the new behaviour to be superior. Me and a few others have tried to convince them that it isn't, but have had no success. If you really want to, you can read the (in some parts unfortunately rather hearted) discussion over on bug #754302.

Despite this apparently not being an option upstream though, somebody is still maintaining a patch that re-enables type-ahead unconditionally, and on arch linux you can build a gtk3 with that patch through the AUR package gtk3-typeahead.
(For nautilus, there is also a patch [one that adds an option, available via dconf], named nautilus-typeahead.)

s/hearted/heated/

My understanding is that typeahead is the behaviour I don't like.  Isn't that what it's called when you start typing and it searches the entire drive instead of bringing you down the list of files?

No, typeahead is the previous behaviour. The new one is called search-as-you-type IIRC.

This is surreal. I don't think anyone can object to NewThings(tm) or to be more specific, the search, but besides the fact that this breaks with decent and deeply ingrained behaviour (you're in a folder, you select a file, you type a letter and it jumps to the first file or folder beginning with that letter), you hard-disable the option to revert back to the old behavior, which empirically is *faster* and *easier* than the new behavior.

I wouldn't even be annoyed, but I'm on KDE and I still get to suffer from this insanity because I use Firefox. 

Dear, dear devs, with all the respect I have for the open source devs of this world, can we please have this an option? Come to your senses!

Yes, please.  It should be an option that can be toggled in dconf or a config file somewhere.  Or at the VERY VERY least a compile-/config-time option.  Not something that needs a patch and recompile of the entire code-base, and might not even work anymore.

By the way, nemo is a good replacement for nautilus.  It's forked from the same code and uses typeahead.

This new "feature" is a big bunch of bullshit and makes everyone having a hard time. It came to my machine with one of the latest Arch Linux updates and I hate it. There's nothing superior on it. I have a well structured directory tree in my Documents folder and I know the names of my files. I don't need a full text search with every open/save window but I need the ability to select my files fast by typing single characters!

Bachsau: As I mentioned in another comment, on Arch Linux, there is the AUR package gtk3-typeahead as a workaround: https://aur.archlinux.org/packages/gtk3-typeahead/

(In reply to Jonas Platte from comment #23)
> Bachsau: As I mentioned in another comment, on Arch Linux, there is the AUR
> package gtk3-typeahead as a workaround:
> https://aur.archlinux.org/packages/gtk3-typeahead/

Yes, I already installed that. This is a temporary fix, but for me it is not an option to always patch and compile this myself for a behavior that should be default. AUR is not a fix. This has to be customizable in dconf!

Strongly agreed.  Given the patch, it would be trivial to have as an option in dconf.

Ideally, it might be good to have the behaviour as an option in the file dialogues even.  I *finally* yesterday, after over a year of suffering, used the search behaviour as it was intended.  It was useful in this one particular instance.  So it could be convenient to be able to easily switch between the two.  But most of the time I want the typeahead behaviour.

The search never highlight the file/folder I want. If I type "bc" I want some files started with "bc" not "abc". Search or not it is the only thing that everyone one. 

P/s: The developer's pride seems hurt so it wont get fix I guess. Shame, it could have been a great new feature, now everyone hates it.

GTK+ became too closely attached to GNOME and GNOME became complete crap. Good desktops should use Qt now.

Is there any way to get rid of this idiotic global search behavior in GTK file dialog boxes on Fedora when using XFCE4?

I'm used to opening the file dialog box and typing the first letter of the file I want and this global search crap really annoys me.

A lot of packages depend on gtk3 so removing that to force gtk2 behavior seems like a bad option. Any way to get programs to use the gtk2 dialog by default?

I opened a related bug on file chooser, please share the reason about you want this feature: https://bugzilla.gnome.org/show_bug.cgi?id=784029

Thanks!

Hi, I'd like to +1 Jonathan, Stefan and Daniel's comments. The new behaviour is very hard to use and essentially breaks directory navigation with tab completion.

I completely agree with Francis Tyers, above.

The current file dialog box's tendency to perform a recursive directory search (rather than to just filter the current directory) is, from the perspective of a user, a severe bug. It hampers usability grievously.

+1 to make this customizable, we have some users asking (legitimately, in my opinion) for the type-ahead behavior.