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 770024 - Wayland: subsurface popovers cause warnings
Wayland: subsurface popovers cause warnings
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Backend: Wayland
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on: 769937
Blocks:
 
 
Reported: 2016-08-17 08:03 UTC by Timm Bäder
Modified: 2018-02-10 12:35 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Timm Bäder 2016-08-17 08:03:56 UTC
Best example is the volume button in the upper left of page2 of the widget-factory.

In mutter, the popover shows up fine but clicking on one of the +/- buttons causes the GtkApplicationWindow to be drawn without a current allocation and the GtkScale doesn't properly update (unless one hovers the scale which causes a queue_allocate iirc).

In weston, this is much more obvious since the entire window looks unfocused after clicking one of the +/- buttons.

There are 2 if-statements in gtkwindow.c that cause the popover to be a subsurface on waylsand, commenting both of them fixes these issues.
Comment 1 Jonas Ådahl 2016-08-17 08:06:41 UTC
Marking this as depending on bug 769937 (port to xdg-shell unstable v6) since we should use non-grabbing "xdg_popup" for popovers.
Comment 2 Jonas Ådahl 2016-08-26 09:06:52 UTC
I bisected this, and sadly ended up on this commit:

    Add a warning for a broken situation
    
    When we emit ::draw, the widget should not have alloc_needed set
    anymore. If this happens, it indicates a broken situation. Add a
    warning to help tracking down why this might occur.
    
    See https://bugzilla.gnome.org/show_bug.cgi?id=765410
Comment 3 Timm Bäder 2016-09-03 14:22:32 UTC
So it looks like I can effectively "solve" this by...

  1) commenting the loop at https://git.gnome.org/browse/gtk+/tree/gtk/gtkwindow.c#n7400 . This will cause the popovers to be realized at a later stage, namely in _gtk_window_set_popover_position here: https://git.gnome.org/browse/gtk+/tree/gtk/gtkwindow.c#n12283 .
  2) Stop the popover from listening to the "parent's" size-allocate by commenting https://git.gnome.org/browse/gtk+/tree/gtk/gtkpopover.c#n2058 . The call to gtk_popover_update_position here might later cause another gtk_widget_queue_resize() through _gtk_window_set_popover_position during a size-allocate though I'm not sure if that's the cause.
  

This is tested with the volumebutton popovers in the widget-factory. The popovers will now popup in the upper left corner.
Comment 4 Matthias Clasen 2016-09-05 02:07:52 UTC
Carlos, can you loook at this ?
Comment 5 Matthias Clasen 2018-02-10 05:08:43 UTC
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.