GNOME Bugzilla – Bug 743427
subsurface-using popovers don't work on Weston
Last modified: 2015-03-02 11:22:46 UTC
When running apps that have a (previously gear-like) menu in the client side decoration area in a Wayland environment (Weston), the menu becomes unusable after you click on it once, then click somewhere else for it to disappear. Future clicks result in button icon being changed, but no drop-down menu is being shown. It happens when I click on a "List" icon near the "X" button in Gedit, for example. The standard menus seem to be unaffected (File, Edit), since such menus work just fine in gnome-terminal and eog when running on Weston. Everything is fine in an X11 environment though.
I can't reproduce this here. The gedit gear menu works just fine for me, multiple times. This is with 3.15.6 here. Can you describe your symptoms more - how is it 'unusable' ?
This one is strange, I can reproduce on weston, but not gnome-shell, there has to be some difference in how both deal with subsurfaces.
Unfortunately, I can't run GTK+3 apps on Weston anymore due to latest GTK+ using xdg-shell API that hasn't been merged into weston yet. But it seems that Carlos has been able to confirm what I said - it doesn't work as it should on weston, it works fine on mutter/gnome-shell.
you can just revert the commit in question locally. It was maybe a bit premature of me to merge it.
(In reply to Armin K. from comment #3) > Unfortunately, I can't run GTK+3 apps on Weston anymore due to latest GTK+ > using xdg-shell API that hasn't been merged into weston yet. But it seems > that Carlos has been able to confirm what I said - it doesn't work as it > should on weston, it works fine on mutter/gnome-shell. There are patches on the list to make Weston support xdg-shell v5, but they haven't even been reviewed, let alone merged. The incredibly annoying thing about GTK+/Mutter merging them - aside from the obvious bit about GTK+ apps not working anywhere else, and non-GTK+ xdg-shell apps not working on Mutter - is that we'd need to bump the proposed v5 to v6 to account for the differences. I know this isn't the best place to be asking, but please, please, please, stop doing this. It's hugely frustrating.
I'm sorry. The premature merging of this patch was entirely my fault.
This is what happens in weston with GTK+-3.15.7 and Jadahl's patches that implement XDG Shell v5 on top of Weston-1.7.0: http://www.linuxfromscratch.org/~krejzi/weston.webm
Note that it was the same when the original bug was reported, with GTK+-3.15.4 and unmodified Weston-1.6.91.
From my investigation, the difference stems from weston not triggering the wl_surface_frame() callback, at least during subsurface initialization. At first, _gdk_window_schedule_update() is called on the just created GDK_WINDOW_SUBSURFACE windows, a blank 1x1 buffer is set, and the surface is damaged. The after-paint signal handler in gdkwindow-wayland.c then freezes the frame clock and does wl_surface_commit(). But the frame callback is supposed to thaw the clock, at this point the clock remains frozen, and no further updates can be triggered, so the subsurface remains with the tiny blank surface. This weston behavior is also seen for weston-subsurfaces, although it manages to just keep pushing frames, which happen to get callbacks after the first time.
So is this a weston bug?
There was more to it... GTK+ does some strange business in creating subsurface GdkWindows, it first creates all relevant wayland interfaces on the window, to just destroy them almost immediately, the interfaces are just created again when the window is shown, this is next to investigate. But this happens when the clock has been already throttled, and weston (rightly, IMO) just silences out the wl_surface_frame callback on a destroyed surface. It's mutter which doesn't remove the destroyed surfaces from the next-to-notify list, which happened to make GTK+ happy. I'm attaching a patch that prepares against this circumstance when gdk_wayland_window_hide_surface() is called mid-frame. This makes popovers work as expected again on Weston.
Created attachment 297878 [details] [review] wayland: Thaw the clock if we hide a GdkWindow mid-frame When a window is hidden, its surface and all its roles are destroyed, if this happens when we already issued a wl_surface_commit and are awaiting for a frame callback, the clock will remain frozen for the next time the window is shown. To avoid this, keep track of the wl_surface_frame() calls issued, and ensure the clock is thawed after hiding. If we happen to receive the frame callback, it is just ignored.
Created attachment 297886 [details] [review] gtkwindow: Do not show subsurface windows for hidden popover widgets This is really just necessary when we have a visible widget, otherwise the window would temporarily linger with odd size and surface.
Created attachment 297887 [details] [review] wayland: Delay wl_subsurface interface creation until the window is shown It isn't really necessary anytime before, so just make sure it's there only when the window is visible.
These last 2 patches fix the early wl_subsurface creation seen in comment #11. For the mutter issue, I've filed https://bugzilla.gnome.org/show_bug.cgi?id=745163
I've applied all 3 patches to gtk+-3.15.9 and the mutter patch to mutter-3.15.90 and everything seems to be working fine now regarding this issue. There's another one, not sure if a direct result of these patches or not, but it's reproducible on both weston and gnome shell wayland. When I click on the gedit menu like in the video, it opens and closes as expected when clicking. But, when I click several times on it to make it open/close more than one time, 1 out of 5 times I need to click twice to get it to open again. That happens on fast clicks only (open/close, open/close, open/close, open/close click in less than 5 seconds).
This (In reply to Armin K. from comment #16) > I've applied all 3 patches to gtk+-3.15.9 and the mutter patch to > mutter-3.15.90 and everything seems to be working fine now regarding this > issue. Great, thanks for testing! > > There's another one, not sure if a direct result of these patches or not, > but it's reproducible on both weston and gnome shell wayland. > > When I click on the gedit menu like in the video, it opens and closes as > expected when clicking. But, when I click several times on it to make it > open/close more than one time, 1 out of 5 times I need to click twice to get > it to open again. That happens on fast clicks only (open/close, open/close, > open/close, open/close click in less than 5 seconds). This is unrelated. Popover transitions are hooked into GtkWidget::show/hide, this means we temporarily cheat during the fade out transition and let the widget shown a little bit longer, so attempts to gtk_widget_show() it meanwhile result in no-op.
Review of attachment 297878 [details] [review]: makes sense to me
Review of attachment 297886 [details] [review]: ok
Review of attachment 297887 [details] [review]: ok
Attachment 297878 [details] pushed as c55fcd3 - wayland: Thaw the clock if we hide a GdkWindow mid-frame Attachment 297886 [details] pushed as d070e4c - gtkwindow: Do not show subsurface windows for hidden popover widgets Attachment 297887 [details] pushed as eaebc2c - wayland: Delay wl_subsurface interface creation until the window is shown