GNOME Bugzilla – Bug 319532
GtkFileChooserButton requests keyring access unnecessarily
Last modified: 2006-10-26 17:30:25 UTC
Please describe the problem: I bookmarked to sftp folders with nautilus for my laptop. now whenever i try to use file open dialog from any gnome app, it tried to access those bookmarked folders as well by requesting the access to the keyring. this is annoying because those sftp folders are not always accessible and most of the time i just want to open the files in the local disk anyway. especially when i dont have access to the internet, the mere action of opening a dialog takes ages, presumably because the app is trying to access the sftp folders and got no response from it. Steps to reproduce: eg. 1. fire up totem 2. click add file bottom 3. Actual results: dialog popup requesting access to keyring, and when there's no access to the network folders, the app freezes for 1 or 2 mins before the file selector dialog pop out. Expected results: do not access the network folders when i dont request it. Does this happen every time? yes Other information:
Hmm yes I can see similar behaviour when I run gnome-screenshot ... probably not the app, but maybe the save dialogue or gnome-vfs tries to access the volumes that are in the "Places" menu. As it constantly keeps asking for the password and/or permission to access the keyring, this *is* annoying. I have been told there must be a duplicate...
I cannot find a duplicate for now. this certainly is not nautilus as it happens with screenshot as well. and when trying to open a file with gedit. Confiming anyways and setting this to gnome-vfs as I assume this is the most suitable product to file agains.
Nope this is a file chooser thingy.
gicmo: Maybe you could be a bit more precise? What's the issue here? Will it be fixed when we have an async GtkFileChooser?
Raising severity as this is extremely user visible.
(In reply to comment #4) > gicmo: Maybe you could be a bit more precise? What's the issue here? Will it be > fixed when we have an async GtkFileChooser? This is not just an issue of asynchronicity, unfortunately. The file chooser essentially needs to stat() a file in order to get its icon. We should distinguish remote URIs and just provide a generic icon for them (optionally, loading the "real" icon as a second stage, and being careful not to prompt for auth in that case --- I'm not sure how that would be done).
*** Bug 332641 has been marked as a duplicate of this bug. ***
*** Bug 321242 has been marked as a duplicate of this bug. ***
This is massively annoying. I find myself doing all sorts of strange things just to avoid opening file choosers coming up, because whenever I do the app hangs for 20-30 seconds trying to check all my bookmarks. A quick hack could be just to provide a generic icon for any bookmark that's not a file:/// url, as suggested in comment #6. Federico, any pointers to code to look at in the hope of hacking up a quick fix?
(In reply to comment #9) > A quick hack could be just to provide a generic icon for any bookmark that's > not a file:/// url, as suggested in comment #6. Federico, any pointers to code > to look at in the hope of hacking up a quick fix? Look at gtk+/gtk/gtkfilechooserdefault.c:shortcuts_insert_path(). Find out exactly where inside that function we block (it could be in the call to get_file_info() or gtk_file_system_render_icon()). Put an "if (!gtk_file_system_path_is_local ())" where appropriate. Don't put it inside gtk_file_system_render_icon() itself; that's a generic function --- the special case needs to be in shortcuts_insert_path(). You'll also want to tweak shortcuts_reload_icons() in that file as well.
Mentioned in https://launchpad.net/distros/ubuntu/+source/libgnomeui/+bug/35027 as well.
Ok, so it seems that we're hitting the network in all of check_is_folder(), get_file_info(), and gtk_file_system_render_icon(). I'm tempted to hack up a patch that doesn't hit the network at all and just displays a stock icon if the path is remote.
(In reply to comment #12) > Ok, so it seems that we're hitting the network in all of check_is_folder(), > get_file_info(), and gtk_file_system_render_icon(). I'm tempted to hack up a > patch that doesn't hit the network at all and just displays a stock icon if the > path is remote. Yes, that would be lovely. We can put this patch in the 2.8 branch, as the file chooser is fully asynchronous in HEAD now.
Created attachment 64672 [details] [review] patch v1 If the file is not a local file, this patch just renders the icon for / . Originally I had done: GtkWidget *image = gtk_image_new_from_stock(GTK_STOCK_DIRECTORY, impl->icon_size); pixbuf = gtk_widget_render_icon (GTK_WIDGET (image), GTK_STOCK_DIRECTORY, impl->icon_size, but this looks very wrong, and moreover the icon size it displayed wasn't correct. I haven't done shortcuts_reload_icons() yet. Patch for that hopefully coming up soon.
Created attachment 64674 [details] [review] patch v2 Better patch. It eliminates all delays and theme switching works too. Federico, could you take a look? (Note: patch is against the GTK 2.8.17 tarball; I don't have a branch tree here.)
Created attachment 64675 [details] [review] patch v2 with fixed end profile message Cosmetic change: fix end profile message
+ if(! gtk_file_system_path_is_local (impl->file_system, path)) + path = "/"; You want path = gtk_file_system_filename_to_path (fs, "/"); ... gtk_file_path_free (path); Please use this spacing: if (!gtk_blah ()) instead of if(! gtk_blah ()) You can't pass "/" to gtk_file_system_render_icon(); it has to be a GtkFilePath. Can you please use g_filename_display_basename() instead of the g_strrstr() thing?
Created attachment 64692 [details] [review] patch addressing Federico's comments
Sweet, thanks! Can you please commit this to the gtk-2-8 branch with a suitable ChangeLog?
Created attachment 64729 [details] [review] final patch Same as previous one, plus fix 2 compilation warnings: +- const GtkFilePath *path; ++ GtkFilePath *path; -+ label_copy = g_filename_display_basename(path); ++ label_copy = g_filename_display_basename((char *)path);
Patch checked in: http://cvs.gnome.org/viewcvs/gtk%2B/gtk/gtkfilechooserdefault.c?r1=1.282.2.17&r2=1.282.2.18&only_with_tag=gtk-2-8 Marking fixed.
note than the GtkFileChooserButton has the same issue which makes you still get lot of authentification dialog when opening many properties dialogs by example (the panel properties is an example)
Created attachment 65408 [details] [review] More places where keyring access is required There are more places where network access is required: change_icon_theme, model_add_bookmarks, test_if_path_is visible, all in filechooserbutton.c Here's an initial version of a patch to remove the network requests. Places where this network access can be seen (after a networked location is bookmarked): gnome-screenshot gnome-terminal (Edit->Current Profile...)
Reopening and reassigning to GTK since the patch is for it. Frederico what with GTK 2.10 the fileselector is asynchronous, but you still get the password dialogs when it then?
Yeah, it's async, but even those requests may require authentication. I think we should just not try to get data for remote URIs in the bookmarks list. Just display a default icon for them.
*** Bug 334210 has been marked as a duplicate of this bug. ***
*** Bug 339962 has been marked as a duplicate of this bug. ***
*** Bug 315420 has been marked as a duplicate of this bug. ***
*** Bug 327466 has been marked as a duplicate of this bug. ***
Ubuntu uses http://people.ubuntu.com/~seb128/009_other_no_io_for_network_bookmark.patch
Christian, that patch is already attached to bugzilla
*** Bug 354887 has been marked as a duplicate of this bug. ***
In bug 354887, I attached the patch that I am using to avoid the authentication dialogs from popping up if "local only" mode has been set.
Hmm, I'm confused here. I don't see authentication dialogs pop up when I open a filechooser which has ssh bookmarks. The authentication dialog only pops up when I click on the bookmark. Has this been fixed on the gnome-vfs side ? Or does this bug only refer to specific protocols ? If so, which ones ?
It is the filechooserbutton which is popping up the authentication dialogs not the filechooser.
Ok, I do see the auth dialog pop up if I select a remote folder in the filechooserbutton combo. Is that what this is about ?
The bug is about the authentification dialogs opened when having a non-local GTK bookmark. The FileChooserButton is one case still having that behaviour. Would you prefer a new bug for it?
I don't have to select anything from the filechooserbutton combo. The authentication dialog just pops up. I can trigger the display of the authentication dialog by either launching gnome-search-tool or right clicking on a panel and selecting the properties menu item. Both dialogs contain a filechooserbutton and local_only mode has been set.
Renaming bug to indicate status.
*** Bug 309907 has been marked as a duplicate of this bug. ***
Bug #354887 seems to be closes to fixing this last issue. Marking as duplicate. *** This bug has been marked as a duplicate of 354887 ***
*** Bug 168020 has been marked as a duplicate of this bug. ***