GNOME Bugzilla – Bug 363147
GTKFileChoser Does not Show Desktop and Home after Uncollapsing an Open File Window
Last modified: 2011-02-04 16:10:53 UTC
Please describe the problem: From Malone: https://launchpad.net/distros/ubuntu/+source/gtk+2.0/+bug/66054 "When saving a file in Firefox or GIMP (for example) the save window appear collapsed and I "Browse Another Folders" is clicked, the "places" section does not show the Home or The Desktop (no text, no icon). this doesn't happen when the window shows up already uncollapsed (i.e opening a file). I'm using Edgy Eft and (if it matters) using the i386 version of the same distro on a AMD64 X2." Steps to reproduce: 1. Open Firefox or GIMP 2. File->Save As 3. The Windows appear, Uncollapse it Actual results: Expected results: Does this happen every time? yeah Other information: Sometimes after collapsing and un-collapsed again or clicking to other it gets fixed. the bug is still present though.
Created attachment 75850 [details] GtkFileChooser bug in Evolution I can verify this on Edgy Eft, amd64.
Created attachment 76385 [details] test case I can confirm this on Gentoo. I've seen this in evolution, firefox, evince. Simple test case attached. If compiled with -DTEST2, the bug doesn't show, if compiled without, the bug can be seen.
*** Bug 373621 has been marked as a duplicate of this bug. ***
Reporters of 363147 and 373621 run on amd64, and commenter Philip as well, probably 64-bits specific.
I can reproduce this in a i386 chroot with an amd64 kernel, though.
I can reproduce the bug on i386 and PPC
Can anyone with appropriate privileges mark this bug as confirmed, and also perhaps increase the priority/severity, seeing as it's clearly been confirmed on i386, amd64 and ppc on various distributions?
Confirming, based on reports on Mandriva 2007.0 http://qa.mandriva.com/show_bug.cgi?id=26644
Created attachment 77336 [details] [review] patch Hi!, Turns out it's a GtkTreeView bug, here's the sequence that triggers the bug: - Home and Desktop entries are added, but with NULL name (which make row_separator_func return TRUE for these rows) - Row sizes are calculated, resulting on a small size for those 2 rows. - The async handler to get info for those 2 folders gets called (get_file_info_finished()), filling the model with complete info, making row_separator_func return FALSE for these 2 rows - The treeview is still not realized, so no new row sizes are calculated when the model changes - When the user expands the file browser, those 2 rows have the same size than separators. This patch removes the GTK_WIDGET_REALIZED() check in gtk_tree_view_row_changed() to let it mark modified nodes as invalid in order to get those rows validated when the treeview is realized.
Thanks a lot Carlos, that indeed fixes the issue.
I applied the patch - it does fix the problem and I haven't noticed any (bad) side effects. Thank you very much, Carlos! Is this patch going to be committed (soon)? Has anyone else tested it (besides Carlos, Josselin and me)?
I'd like to hear Kris' comment on the patch.
I fully understand the reasoning for this patch, and see why it does work :) However the comment which is being removed makes me want to take a little deeper look this week before I want to approve. (I suspect that the "we don't care about sizes when not realized" rule broke when we started to validate rows in _size_request(); this change has been made a long time ago and I want to see if there is more code which relies on this fact).
*** Bug 386570 has been marked as a duplicate of this bug. ***
Carlos, sorry for not getting back earlier. Just removing the REALIZED check is going to cause some problems, so I am going to refactor _row_changed() in a slightly different way. I have 1/2 a patch for this on my other machine, but the vfs backend module isn't fully working there at the moment so can't reproduce the bug (I have an idea where that problem is though :). Will get it fixed RSN. Putting on 2.10.7 milestone.
(In reply to comment #15) > Carlos, sorry for not getting back earlier. Just removing the REALIZED check > is going to cause some problems, so I am going to refactor _row_changed() in a > slightly different way. I have 1/2 a patch for this on my other machine, but > the vfs backend module isn't fully working there at the moment so can't > reproduce the bug (I have an idea where that problem is though :). It's reproduced just fine with gtk backend.
(In reply to comment #16) > It's reproduced just fine with gtk backend. Ah, you're right; my bad. Committed a fix on HEAD and gtk-2-10; just too late for 2.10.7 unfortunately ... 2007-01-05 Kristian Rietveld <kris@gtk.org> * gtk/gtktreeview.c (gtk_tree_view_row_changed): do allow to invalidate nodes if the tree view is not realized. (#363147, Carlos Garnacho, Miguel Cabrera).
*** Bug 427554 has been marked as a duplicate of this bug. ***