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 710888 - GtkInfoBar not shown after calling gtk_widget_show
GtkInfoBar not shown after calling gtk_widget_show
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
3.22.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
: 764784 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-10-25 16:45 UTC by Paolo Bacchilega
Modified: 2018-03-12 15:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Example that shows the problem (1.08 KB, text/plain)
2013-10-25 16:45 UTC, Paolo Bacchilega
  Details
Another testcase (2.56 KB, text/plain)
2016-03-28 09:52 UTC, Christophe Fergeau
  Details
testinfobar: Add simple test of :visible/:revealed (3.62 KB, patch)
2018-03-12 15:30 UTC, Daniel Boles
committed Details | Review

Description Paolo Bacchilega 2013-10-25 16:45:18 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.
Comment 1 Christian Persch 2013-11-29 15:21:24 UTC
Doesn't happen when enable-animations=false. However the patch in bug 719510 doesn't fix this.
Comment 2 Volker Sobek (weld) 2013-12-11 00:03:08 UTC
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 ...
Comment 3 Milan Crha 2015-03-31 08:15:39 UTC
Still reproducible with 3.14.6.
Comment 4 Paolo Bacchilega 2015-03-31 10:56:25 UTC
...and with 3.16.0 as well.
Comment 5 Matthias Clasen 2015-03-31 14:00:08 UTC
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.
Comment 6 Milan Crha 2015-04-01 05:56:13 UTC
(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.
Comment 7 Milan Crha 2015-11-18 10:37:05 UTC
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);
    }
Comment 8 Christophe Fergeau 2016-03-28 09:52:22 UTC
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.
Comment 9 Cédric Bellegarde 2016-05-02 06:47:41 UTC
https://bugzilla.gnome.org/show_bug.cgi?id=764784

Linked bug I think.
Comment 10 Debarshi Ray 2016-05-02 17:04:34 UTC
*** Bug 764784 has been marked as a duplicate of this bug. ***
Comment 11 Debarshi Ray 2016-05-03 15:10:25 UTC
(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.
Comment 12 Alex Băluț 2016-06-23 08:16:37 UTC
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
Comment 13 Ahmet Öztürk 2016-08-21 06:23:11 UTC
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.
Comment 14 Bilal Elmoussaoui 2017-01-05 22:47:53 UTC
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.
Comment 15 Timm Bäder 2017-05-05 09:30:39 UTC
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).
Comment 16 Timm Bäder 2017-06-06 11:55:34 UTC
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).
Comment 17 Daniel Boles 2017-09-05 18:41:03 UTC
I'll try to test this out sometime soon and see if it's suitable for 3.22
Comment 18 Stephen Brandt 2018-03-03 22:57:19 UTC
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
Comment 19 Cédric Bellegarde 2018-03-04 12:07:39 UTC
Here, calling queue_resize() after show() fixes the issue.
Comment 20 Maxime DOYEN 2018-03-11 18:10:04 UTC
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.
Comment 21 Hakan Bayındır 2018-03-11 21:35:37 UTC
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.
Comment 22 Timm Bäder 2018-03-12 07:52:43 UTC
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.
Comment 23 Daniel Boles 2018-03-12 15:30:02 UTC
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.
Comment 24 Daniel Boles 2018-03-12 15:33:24 UTC
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