GNOME Bugzilla – Bug 696882
[regression] GtkWindow changes size after hide/show cycle
Last modified: 2013-05-31 22:25:27 UTC
Created attachment 240144 [details] Test case Calling gtk_widget_hide() and then gtk_widget_show() on a GtkWindow changes the size of the window since https://git.gnome.org/browse/gtk+/commit/?id=b495ce5446a0bbf2ed63b5880537779e4b123515. This was originally reported to Audacious as http://redmine.audacious-media-player.org/issues/259. Test case attached. Notice how the shown window is initially around 200x200 pixels but changes to 1x1 after the first hide/show cycle. Using the mouse to resize the window also makes no difference; the size again reverts to 1x1 after the next cycle.
Created attachment 240201 [details] [review] Fix #696882: window would revert to minimum size after hide/show Fixes the issue by returning a different allocation when not visible (as seem to have been the intent of the orginal commit), but while preserving the allocation for when the widget is made visible again.
Review of attachment 240201 [details] [review]: minimal review, it will still need a formal review from Matthias and/or Benjamin. ::: gtk/gtkwidget.c @@ +13916,3 @@ + if (priv->visible) + *allocation = priv->allocation; coding style: only two spaces for the indentation. @@ +13918,3 @@ + *allocation = priv->allocation; + else + *allocation = (GtkAllocation) { -1, -1, 1, 1 }; this is a GCC-ism, and it's not portable. it should be rewritten in a portable way. also, coding style (as above).
Created attachment 240558 [details] [review] Fix #696882: window would revert to minimum size after hide/show
This doesn't fix bug 697275, where it ignores the values set using gtk_window_set_default_size().
Lots of bugs this doesn't fix ;-) Was that bug also introduced by b495ce5446a0? Also, do you have a test case for it? Trying a simple code that creates a window, calls gtk_window_set_default_size() and shows the window have it at the expected size.
This patch fixes the resize problem but does not fix the abort for me in the audacious bug report: gtk_widget_unregister_window: assertion failed: (user_data == widget) Aborted
I experienced the abort bug with 3.7.12 but 3.8.0 fixed it. Are you sure you are not using an older version?
I am definitely using 3.8.0. It seems to be a problem with GtkStatusIcon in gtk+-3.8.0, as I have the same problem, with the same backtrace, with another program. If I am the only one experiencing this and if I have time I will try some tests on GtkStatusIcon over the weekend (I may not).
The GtkIconStatus bug is trivially reproducible with GTK+-3.8.0 and I have filed a separate bug #697427 for that.
Created attachment 240952 [details] [review] window: restore size after hide/show properly Old code assumed the size was stored in widget.allocation. This is no longer true as the allocation is cleared upon hide. However, we store the last configure request, and that one tracks the last size, so we can just use that number. Sometimes things are so easy - once you figure them out...
That's the patch I'm gonna push to master - and to gtk-3-8 unless issues show up. I'd be happy if people could test that it fixes all the issues they've been seeing. I only checked that it fixes the attached test.
It also fixes the bug with Audacious, thanks for your patches.
(In reply to comment #12) > It also fixes the bug with Audacious, thanks for your patches. Sorry, I was wrong. If you resize the window and click twice on the statusicon, the size is not the new one.
Created attachment 240985 [details] Test case #2 I confirm Thomas's observations, the test case is fixed but Audacious is still broken. Here is a second test case that is closer to what Audacious actually does. The only difference is the addition of a gtk_window_get_position() right before gtk_widget_hide() and a corresponding gtk_window_move() right before gtk_widget_show().
In my testing, I'm applying the patch on top of 3.8.0, btw.
Hrm, the testcase works here with master.
I tried master and it is still not working here (the window reverts to 200x200 now instead of 1x1, however). Screencast: https://www.box.com/s/bvtqc1sfskdpiai5qq1u
Pushed c4dc0e8e40e2144d84810f7603c9d1552e25fb43 as another fix for the issue you pointed out. Also pushed the patches to the gtk-3-8 branch. And now I'm closing this, please reopen if there's still things broken.
Seems to be fixed.
(In reply to comment #19) > Seems to be fixed. Which branch? I have tested gtk-3-8 and Audacious still does not restore the size if I resize it manually and click the status icon. But your test case #2 works fine now.
Created attachment 241215 [details] Test case #3 Hmm, not fixed yet after all. Adding a call to gtk_window_set_default_size() causes the window to forget its size again and always come back at the default size. Attaching test case #3.
Yeah, another way it manifests itself is on window using an expander. When toggling an expander the window will be reset to its default size, thus undoing any user/manual resize previously done. This can be seen by using the expander example from gtk3-demo, only replacing the call to gtk_window_set_resizable() with one to gtk_window_set_default_size()
Just hit this with GTK 3.8.1 on a GNOME 3.8 system. It's affecting Evolution badly, but now giggle is doing it too. AfC
It effects empathy VERY badly too. Every single time the contact list updates it resizes to become super-wide. Massive regression and very annoying :( Using arch linux with gtk 3.8.1-1 other apps that are affected are disks, inkscape.
*** Bug 698795 has been marked as a duplicate of this bug. ***
*** Bug 698841 has been marked as a duplicate of this bug. ***
*** Bug 698811 has been marked as a duplicate of this bug. ***
So, I've been running GTK 3.8.1 with the fix (38b62e46) reverted, and using the patch I submitted earlier instead. AFAICS it fixes the original bug without introducing new ones, e.g. hiding/showing windows or windows w/ expander work as expected, as do all submitted test cases. (I don't use Audacious or any of the other mentionned apps, so I didn't check that.) (The only thing I noticed was a bug in tooltip placement, but that only made it happen all the time, whereas it would otherwise happen on some occasions only. Either way, a patch is here: https://bugzilla.gnome.org/show_bug.cgi?id=698730) Seems to me that this would fix the issue properly. Now, the committed fix does change behavior in GtkWindow, but the original commit (b495ce54) wasn't about GtkWindow but GtkWidget, so even if the new bugs were fixed, wouldn't that left things not the way they should, one way or another? (e.g. after setting visible to FALSE on a widget, get_allocation() doesn't return { -1, -1, 1, 1 } as was the intent) Comments?
Another problem with the commit 38b62e46 (en the gtk-3-8 branch): When a GtkWindow is hidden and then shown again, the child widget is not visible anymore. The "visible" property on the child widget doesn't change and is TRUE, so there is a problem.
*** Bug 698806 has been marked as a duplicate of this bug. ***
*** Bug 699299 has been marked as a duplicate of this bug. ***
*** Bug 698584 has been marked as a duplicate of this bug. ***
*** Bug 699449 has been marked as a duplicate of this bug. ***
Still not fixed with commit https://git.gnome.org/browse/gtk+/commit/?id=2d29c4a43fbdab4d9fcae2589cf729b2dd1c3783. If you reduce the window size, the default size is restored in testcase #1 and #2. Tested with GTK master.
This very annoying bug is still alive and well on GNOME 3.8.1 using GTK 3.8.1-2.4. Any new developments? I would be glad to help with testing a fix.
Yes, this bug is quite annoying in its current manifestation. The easiest workaround is to simply revert the commit 38b62e46. Here's a patch that reverts that commit. I had to resolve a merge conflict in making this, so you'll find it easier to apply this patch than to run 'git revert' directly. It applies cleanly to the head of the gtk-3-8 branch.
Created attachment 243593 [details] [review] patch to revert 38b62e46 as a workaround
You just made my day :-D . I am going to apply it right now! THANKS! (In reply to comment #36) > Yes, this bug is quite annoying in its current manifestation. The easiest > workaround is to simply revert the commit 38b62e46. Here's a patch that > reverts that commit. I had to resolve a merge conflict in making this, so > you'll find it easier to apply this patch than to run 'git revert' directly. > It applies cleanly to the head of the gtk-3-8 branch.
What patch I need apply ?
(In reply to comment #39) > What patch I need apply ? The patch I attached in comment #37. You could do this, for example: ~/src/gtk+$ git am 0001-Revert-window-restore-size-after-hide-show-properly.patch ~/src/gtk+$ make ~/src/gtk+$ make install
Though obviously simply reverting 38b62e46 doesn't fix the original bug. However as said earlier, using the patch from comment #3 should do the trick.
I hadn't realized that the patch from comment 3 actually did correct the bug! I thought that it was said that none of those patches fixed it. After reading everything again I see that we may be dealing with more than the just the one bug that comment 3 fixes. We should probably try to get separate bug reports started if that's is the case. Anyway, maybe someone here help me out. I spent 3 hours last night on yet another linux learning maze (lol) trying to apply the patch that was posted yesterday. I have the branch from git cloned locally and I successfully applied and committed the patch to the branch I created. Where do I go from this point to actually have the patched version installed on my system? If someone could point me in the right direction, I'd really appreciate it. Thanks!
(In reply to comment #42) > Where > do I go from this point to actually have the patched version installed on my > system? If someone could point me in the right direction, I'd really appreciate > it. Thanks! Unfortunately that's not a question with a simple answer. In theory, you could simply run 'make' followed by 'make install'. In practice you may hit the following issues: - If you install GTK in /usr/local, then it may be unable to find your theme and other libraries it needs unless you install those in /usr/local too. - If you install in /usr, you're clobbering your system installation of GTK which is a bad idea. - If you're running a system such as Ubuntu which applies its own patches to GTK, then installing a GTK built directly from a clone of the GNOME repository may lead to odd behaviors. The most straightforward path forward is probably to rebuild your system's GTK package having applied this patch. Just how to do that depends on which operating system you are on. This is getting off-topic for this bug, so I'd suggest following up on a mailing list such as gnome-love to get more help with this.
Ok, Ill do that. Thanks so much for the response! I am assuming since today is Thursday that someone will be updating this bug to at least CONFIRMED? I was going to ask in the IRC but after reviewing the triage wiki decided to hold off.
Please try current git master or the gtk-3-8 branch. I've pushed a few fixes that make all our window-sizing related tests pass. If you find that there are still problems in apps, please reopen this bug or file a new one.
(In reply to comment #45) > Please try current git master or the gtk-3-8 branch. I've pushed a few fixes > that make all our window-sizing related tests pass. > > If you find that there are still problems in apps, please reopen this bug or > file a new one. I will test it at the night. But it's very good news =)
(In reply to comment #45) > Please try current git master or the gtk-3-8 branch. I've pushed a few fixes > that make all our window-sizing related tests pass. > > If you find that there are still problems in apps, please reopen this bug or > file a new one. yeah ! All works fine ! I love you =)
Awesome! I'll test it when I get home this evening and will hopefully be posting good news afterwards! -Dustin
That's awesome. . This was an annoying bug. Thanks for all your work!
ReOpen bug, please. Empathy main window always on restart changed to: -geometry 569x600+-9+19 I created Bug 700196 that I am not sure that it belongs to the current bug
The original bug report http://redmine.audacious-media-player.org/issues/259 is fixed now. Thanks a lot.
*** Bug 700089 has been marked as a duplicate of this bug. ***
*** Bug 699969 has been marked as a duplicate of this bug. ***
*** Bug 700795 has been marked as a duplicate of this bug. ***
*** Bug 696187 has been marked as a duplicate of this bug. ***