After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 672271 - File chooser seems over-enthusiastic about using subdirectories
File chooser seems over-enthusiastic about using subdirectories
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: GtkFileChooser
3.3.x
Other Linux
: Normal normal
: ---
Assigned To: Federico Mena Quintero
Federico Mena Quintero
: 673448 673577 682047 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2012-03-17 01:58 UTC by Adam Williamson
Modified: 2017-08-24 22:19 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
When selecting a folder in the file chooser entry include the current directory (1.47 KB, patch)
2013-06-14 14:04 UTC, Garrett Regier
none Details | Review
bgo672271.patch (1.72 KB, patch)
2013-06-21 23:51 UTC, Federico Mena Quintero
committed Details | Review

Description Adam Williamson 2012-03-17 01:58:23 UTC
Simple example: I want to download a file using Transmission. I have a directory structure like so:

/files
  /foo
    /foo-subdir
  /bar
  /monkeys
    /monkeys-subdir

All the files I want to download will go into one of the subdirectories of /files. I have transmission's default directory set up as /files. So I click on a torrent, Transmission opens up a dialog with a 'Destination folder' option, which defaults to /files as I specified. I want this file to go into /files/foo , so I click /files which turns into a drop-down list of recently-used folders, with 'Other' at the bottom. I click on 'Other', and the GTK+ file chooser opens up, in /files . I double-click /foo, hit Enter, and...

the files wind up in /foo/foo-subdir .

What the hell? It never used to do that. I don't think my actions indicated that I *wanted* it to do that.

If I single-click /foo, it works, but still, this is a big change in behaviour which is *constantly* screwing me up with lots and lots of apps (the above example is just the most common case - I keep downloading files and thinking they've disappeared until I remember to look in the first named subdirectory of whatever directory I *thought* I was putting them into).
Comment 1 Filippo Argiolas 2012-11-05 09:10:39 UTC
I can still reproduce it in 3.6, see also bug #673448 which looks like a duplicate (commenting here as it has a better description of the issue).

See also https://bbs.archlinux.org/viewtopic.php?id=142989

I wouldn't call it just a change in behaviour though, looks like a real bug and it's pretty annoying especially with Transmission. It seems to happen only if location bar (Ctrl + L) is visible, hiding it makes everything behave as expected.
Comment 2 Adam Williamson 2012-11-05 15:44:07 UTC
I've more or less gotten used to it by now. The 'trick' is to just _select_ the directory name, not to enter the directory. So if you want the file in /files/foo , go to /files and just click on foo/ , don't double-click it. I still forget sometimes, but...
Comment 3 Filippo Argiolas 2012-11-05 16:21:54 UTC
That seems true but it cannot be achieved if e.g. you want to select a directory just from the sidebar (e.g. Videos or Downloads). If I click on Videos from the sidebar and the location bar is enabled the first directory inside Videos gets appended to the path and "single click on Videos -> Open" doesn't select Video directory but "Videos/first_sub_dir".
Comment 4 Adam Williamson 2012-11-05 17:32:20 UTC
Yeah, I concur. I think that part is clearly a bug.
Comment 5 Daniel Aleksandersen 2013-03-22 01:17:30 UTC
This issue is only one of two that is disruptive in my daily use of Linux as a desktop operating system. I hope it can be prioritized.
Comment 6 Matthias Clasen 2013-03-22 13:31:47 UTC
*** Bug 673448 has been marked as a duplicate of this bug. ***
Comment 7 Adam Dingle 2013-04-21 09:46:37 UTC
I agree this is an annoyance.  Really the problem is that as soon as you enter a directory which has only a single subdirectory, the file chooser automatically fills in the Location field with the name of that subdirectory.  I think it should leave the Location empty in this case.
Comment 8 Adam Williamson 2013-05-10 19:40:57 UTC
I'm still fighting this one. I've mostly trained myself for it, but here's a really annoying case I just came across. Say I add directory /foo/bar to my bookmarks, because I use it all the time. It has a subdirectory, /foo/bar/moo . If I just want to quickly save something into /foo/bar it's annoyingly inefficient, because I have to click my /foo/bar bookmark and then navigate up one level to /foo; if I just click my /foo/bar bookmark and hit "Save", the file winds up in /foo/bar/moo . Grrr.
Comment 9 Adam Dingle 2013-05-10 20:05:43 UTC
True.  As a workaround, you can add a second dummy subdirectory to /foo/bar.  As I pointed out, the bug rears its head only when a directory has just one subdirectory.
Comment 10 Garrett Regier 2013-06-14 14:04:56 UTC
Created attachment 246812 [details] [review]
When selecting a folder in the file chooser entry include the current directory

When selecting a folder in the file chooser entry include the current directory

Otherwise we would automatically autocomplete the subdirectory,
causing the wrong directory to be selected.
Comment 11 Federico Mena Quintero 2013-06-21 16:06:15 UTC
The analysis of "the file chooser in SELECT_FOLDER mode puts the first directory in the location entry, if there is a single directory in the folder you just entered", is correct.

And while the patch in comment #10 indeed causes the file chooser's entry *not* to put the directory name in the entry, it's not completely correct.  It has the side effect of introducing a filename that does not exist in the current directory.

E.g. create a directory called /foo, and inside it create a subfolder called foobar.

So you have

  foo
    foobar

With the patch in place, when you visit the foo directory, the file chooser's entry gets populated with "foo".  And once you trigger completions, you see both "foo" and "foobar" in the completion list, which is clearly wrong.

The basic question is, why is the file chooser entry auto-filling the first option it finds when there is only a single subdirectory in the current directory?
Comment 12 Federico Mena Quintero 2013-06-21 17:25:02 UTC
And the answer is as follows.  GtkFileChooserEntry creates a GtkFileSystemModel and populates it for the current folder.  It does that as soon as you switch to the first subdirectory, in response to the main file chooser telling it that the base folder has changed.  As soon as the model is created, it gets set on the GtkEntryCompletion.

So, the GtkFileSystemModel starts loading in the background.  It finishes loading, it emits "finished-loading", and the GtkFileChooserEntry explicitly asks the GtkEntryCompletion to insert the completion prefix (see the end of finished_loading_cb(), where it calls gtk_entry_completion_insert_prefix().

This is done so that *while typing*, GtkFileChooserEntry will be able to suggest a completion as soon as possible.  But this bug shows that this is clearly wrong when the entry is supposed to be empty, i.e. when you just switched folders.

Here is the backtrace where the completion prefix is inserted:

(gdb) where
  • #0 entry_completion_insert_prefix_cb
    at gtkfilechooserentry.c line 163
  • #1 _gtk_marshal_BOOLEAN__STRING
    at gtkmarshalers.c line 2244
  • #2 g_closure_invoke
    at gclosure.c line 777
  • #3 signal_emit_unlocked_R
    at gsignal.c line 3582
  • #4 g_signal_emit_valist
    at gsignal.c line 3336
  • #5 g_signal_emit
    at gsignal.c line 3382
  • #6 gtk_entry_completion_insert_prefix
    at gtkentrycompletion.c line 1900
  • #7 finished_loading_cb
    at gtkfilechooserentry.c line 566
  • #8 g_cclosure_marshal_VOID__POINTERv
    at gmarshal.c line 1236
  • #9 _g_closure_invoke_va
    at gclosure.c line 840
  • #10 g_signal_emit_valist
    at gsignal.c line 3234
  • #11 g_signal_emit
    at gsignal.c line 3382
  • #12 gtk_file_system_model_got_files
    at gtkfilesystemmodel.c line 1200
  • #13 next_async_callback_wrapper
    at gfileenumerator.c line 311
  • #14 g_task_return_now
    at gtask.c line 1108
  • #15 complete_in_idle_cb
    at gtask.c line 1117
  • #16 g_idle_dispatch
    at gmain.c line 5235
  • #17 g_main_dispatch
    at gmain.c line 3058
  • #18 g_main_context_dispatch
    at gmain.c line 3634
  • #19 g_main_context_iterate
    at gmain.c line 3705
  • #20 g_main_loop_run
    at gmain.c line 3899
  • #21 gtk_main
    at gtkmain.c line 1157
  • #22 main
    at testfilechooser.c line 756

Let me think about the right place in the code to put a check against the entry not requiring inline completion even when the file system model finishes loading...
Comment 13 Federico Mena Quintero 2013-06-21 23:48:24 UTC
Got it!  finished_loading_cb() was causing the GtkEntryCompletion to insert the completion prefix, even if the entry didn't have the focus.

You definitely want the prefix inserted while you are typing in the entry.  But when the file system model is changed due to the whole file chooser changing the current folder, you don't want the prefix inserted.  This is what caused the bug.

I've pushed a fix to the master branch in commit 9162589b5.
Comment 14 Federico Mena Quintero 2013-06-21 23:51:05 UTC
Created attachment 247499 [details] [review]
bgo672271.patch
Comment 15 Adam Williamson 2013-06-22 00:01:17 UTC
Thanks much, Federico! It'd be great if this could be backported to older branches, so it doesn't annoy me for the next 12 months until all my systems are on GTK 3.10 or whatever :)
Comment 16 Adam Williamson 2013-06-22 00:03:00 UTC
Federico: will this also fix https://bugzilla.gnome.org/show_bug.cgi?id=700321 ? if not, do you feel like tackling that one too? :)
Comment 17 Federico Mena Quintero 2013-06-22 00:22:26 UTC
Pushed to gtk-3-6 as commit 62f971be.
Pushed to gtk-3-8 as commit 5aae1ead.

(In reply to comment #16)
> Federico: will this also fix https://bugzilla.gnome.org/show_bug.cgi?id=700321
> ? if not, do you feel like tackling that one too? :)

That one is SUPER annoying.  I think I just found a reliable way of reproducing it.  I'll fix it next.
Comment 18 Timothy Arceri 2013-06-24 03:56:55 UTC
*** Bug 682047 has been marked as a duplicate of this bug. ***
Comment 19 Adam Williamson 2014-03-19 03:12:58 UTC
Something rather similar to this seems to have come back recently (3.11.8?). Anyone else seeing it?
Comment 20 Daniel Boles 2017-08-24 22:19:32 UTC
*** Bug 673577 has been marked as a duplicate of this bug. ***