GNOME Bugzilla – Bug 710888
GtkInfoBar not shown after calling gtk_widget_show
Last modified: 2018-03-12 15:33:29 UTC
Created attachment 258137 [details] Example that shows the problem If I call gtk_widget_hide and gtk_widget_show in sequence on a GtkInfoBar it should always be visible because the call to gtk_widget_show should nullify the call to gtk_widget_hide, but this is not always the case. The attached example shows the problem. When clicking the button the info bar should remain always visible, instead it is intermittently hidden and shown. I think the problem is with the revealer used internally by the info bar.
Doesn't happen when enable-animations=false. However the patch in bug 719510 doesn't fix this.
The problem is that calling gtk_widget_show() on an info bar while it is in the hiding animation does not result in calling gtk_info_bar_show because gtk_widget_get_visible (widget) returns TRUE as long as the hiding animation is in progress, and thus gtk_info_bar_show() isn't called at all. Only once the hiding animation is done, child_revealed() in gtkinfobar.c calls GTK_WIDGET_CLASS (gtk_info_bar_parent_class)->hide (widget) and only after that one can successfully call gtk_widget_show() on the info bar again. I have a feeling that animations and gtk_widget_show/hide would better stay orthogonal ...
Still reproducible with 3.14.6.
...and with 3.16.0 as well.
It is generally not necessary to update bugs with such by-the-minute version information. If nobody touched it, it is generally assumed to still apply.
(In reply to Matthias Clasen from comment #5) > It is generally not necessary to update bugs with such by-the-minute version > information. If nobody touched it, it is generally assumed to still apply. Right, though it sometimes happens to me that I fix something and then realize that there is a bug for it filled, or the bug is a duplicate of something already fixed. It's just that I do not have an idea about each single bug report, thus some can be overlooked, even already fixed.
My current workaround for the bug is to disable the revealer animation on the infobar: revealer = gtk_widget_get_template_child (GTK_WIDGET (object), GTK_TYPE_INFO_BAR, "revealer"); if (revealer) { gtk_revealer_set_transition_type (GTK_REVEALER (revealer), GTK_REVEALER_TRANSITION_TYPE_NONE); gtk_revealer_set_transition_duration (GTK_REVEALER (revealer), 0); }
Created attachment 324865 [details] Another testcase This problem seems to have gotten worse between gtk+ 3.18 and 3.20. Even with a 2 seconds delay between hide() and show(), the GtkInfoBar does not show again with gtk+ master (3.20.0-40-ga4ed154) while this works fine with my system gtk+ (gtk3-3.18.9-1.fc23.x86_64) This might be a different issue than what is described here, but since the workaround from comment #7 helps, I'm adding this information here.
https://bugzilla.gnome.org/show_bug.cgi?id=764784 Linked bug I think.
*** Bug 764784 has been marked as a duplicate of this bug. ***
(In reply to Milan Crha from comment #7) At the risk of going off-topic ... > My current workaround for the bug is to disable the revealer animation on > the infobar: > > revealer = gtk_widget_get_template_child (GTK_WIDGET (object), > GTK_TYPE_INFO_BAR, "revealer"); > if (revealer) { > gtk_revealer_set_transition_type (GTK_REVEALER (revealer), > GTK_REVEALER_TRANSITION_TYPE_NONE); > gtk_revealer_set_transition_duration (GTK_REVEALER (revealer), 0); > } I think a better option / workaround would be to put the GtkInfoBar explicitly inside a GtkRevealer. Poking at the internals through gtk_widget_get_template_child is almost like having our own definition of GtkInfoBarPrivate.
This bug is very nasty since it's difficult to notice, at least for cases when the 2nd appearance of the infobar happens rarely. From far away I'd say the hide method is broken, since it does not leave the widget in the same state as when it is initially created, so the show method does not work the second time, while it works just fine the first time. Example of Python workaround similar to comment #7 https://phabricator.freedesktop.org/D1103#34aa2703
Removing and reattaching the infobar from/to its container also works for me. You can just remove after hiding and attach before showing or remove and attach just before showing, both work but I prefer the first one.
I still can confirm this bug on Gtk 3.22.6, on this link https://github.com/jangernert/FeedReader/issues/298#issuecomment-270774094 you will find a code example on Python & Vala, that might help you reproduce that.
I wonder if we should backport the API addition from master to gtk-3-22, i.e. commit 1bb4f1e9d9c4fb54e1a4b4e05bf6c5d1302f00d3 (which depends on commit e3871c4424081cc521e7ec6502ef5cfb6a535b2a but not necessarily).
FWIW I think it would be fine to push them to gtk-3-22 if someone makes sure that the code just using gtk_widget_show/hide doesn't break (but not animating anymore is fine).
I'll try to test this out sometime soon and see if it's suitable for 3.22
I recently noticed my application was also affected by this bug since Gtk 3.20 onwards. As workaround I have wrapped the infobar inside a revealer and disabled animation on the infobar revealer child: https://github.com/ztefn/haguichi/commit/0ddac0aedc10295bfd96996a85cb8bcb98aca772#diff-3baebc2923ecb53c11b57deff247b56c
Here, calling queue_resize() after show() fixes the issue.
Bug still under gtk+ 3.22.25 This might be something related to resize or focus, because if you sequence as follow: - hide the infobar - show the infobar - then make the window out of focus - then focus the window again => the bar appear you can easily reproduce this with gtk3-demo / infobar section As infobar purpose is to warn user on important things, a fix would be more than welcome.
Infobar is used in crucial places like login managers, and used to communicate processes like password changes after expiration. This bug makes these processes un-navigable since users cannot read the prompts. I actually experienced the same problem in some projects that I took part.
We already know what the problem is and how to fix it. It's described in Commment 15 and Comment 16. Someone just has to take a 30 minute break from posting "me too" comments on bugzilla and backport+test those patches.
Created attachment 369580 [details] [review] testinfobar: Add simple test of :visible/:revealed This exists merely to prove that, having added ::revealed, show() and hide() now work reliably, as does set_revealed() for the animated case.
It seems to work fine, so let's land it, along with a new (very basic) test. Attachment 369580 [details] pushed as 6b4d95e - testinfobar: Add simple test of :visible/:revealed