GNOME Bugzilla – Bug 786029
clicking on gtk-slider makes the parent disappear
Last modified: 2017-08-28 18:11:26 UTC
Created attachment 357227 [details] slider I upgraded to gtk3-3.22.18.1 yesterday. xfce-panel plugins with a slider - for example, the power-manager plugin (https://docs.xfce.org/xfce/xfce4-power-manager/1.4/panel-plugin) with the brightness slider. When I try dragging the slider, the parent window disappears (loses focus) and the slider value is not changed. I downgraded to gtk3-3.22.17-1 and the slider is fine.
The only commit that could affect GtkScale is https://git.gnome.org/browse/gtk+/commit/?h=gtk-3-22&id=9b032073cbcf5aadbeb4b74f0cf662a9fa5f5530 afaics
Is this related? https://mail.gnome.org/archives/gtk-list/2001-May/msg00228.html I enabled debug for xfce-panel and didn't get anything on the output significant when the issue happens. To break it down, I put a firefox window exactly behind where the brightness slider appears, so that I would know if the window behind is getting focus when I click on the slider. This is what happens, - I click on the slider to start dragging - On button down, the slider overlay disappears - The window behind was not in focus I am a noob at GTK-ing. Can I help anyway?
I must add, when I use my mouse scroll to change the slider value, it works perfectly (the overlay doesn't disappear).
@Timm You are correct! I reverted the commit 9b032073cbcf5aadbeb4b74f0cf662a9fa5f5530 locally, built GTK+, replaced /usr/lib/libgtk-3.so.0.2200.18 with the one I built and the slider works perfectly now without issues. What does gtk_grab_add do in gtkrange.c (in simple terms) ?
Created attachment 357334 [details] [review] menu: Avoid cancelling the menu on GTK+ grabs inside the GtkMenu Allows again sliders as menuitems, broken by commit 9b032073.
Please notice that the patch is untested, I think the problem basically comes down to GtkRange being used inside a GtkMenuItem, which neither GtkRange nor GtkMenu expect, but I have no test app that tries to do the same.
Using ranges inside menus is really not a supportable (or supported) configuration.
@carlosg: A Xubuntu dev packaged it up in a PPA and your patch was successfully tested. @mclasen: While I would agree in general the specific case here is having a slider in a panel plugin, which you also have in gnome shell (e.g. for adjusting the audio volume) which makes it again a fairly acceptable use-case - especially in a world before gtkpopover. (When this specific widget was created there was no gtkpopover.)
In case anyone wonders, the PPA is to be found here: https://launchpad.net/~xubuntu-dev/+archive/ubuntu/xubuntu-staging/+packages
(In reply to Simon Steinbeiss from comment #8) > @mclasen: While I would agree in general the specific case here is having a > slider in a panel plugin, which you also have in gnome shell (e.g. for > adjusting the audio volume) which makes it again a fairly acceptable gnome-shell does not use GTK, and a compositor can handle grabs-inside-grabs much more gracefully than a generic client-side toolkit like GTK. I'd be very wary about extrapolating acceptable behaviour from that.
@ebassi: My argument was not technical, but use-case based. In this sense I still believe "it" (the use-case) is acceptable. With regard to "how well it works" or whether the result of what you may consider fugly custom widgetry is "acceptable" for end-users I would point to not just Xfce, but also Unity as DE using it for many years (since the inception of "ayatana indicators"). And finally yeah, I already agreed in my comment that I'm aware that GtkMenuItems and GtkRanges were not conceived with this use-case/scenario in mind and I understand why you're not happy to encourage this type of widget-usage. However in this case I would hope that the minimal impact of the patch on your code-base and the fairly large impact on users of Xfce and Unity outweighs your concerns. Would you say GtkPopovers are a suitable replacement at all then for the future or what would you advise us to migrate to?
(In reply to Simon Steinbeiss from comment #11) > GtkMenuItems and GtkRanges were not conceived with this use-case/scenario in > mind and I understand why you're not happy to encourage this type of > widget-usage. > However in this case I would hope that the minimal impact of the patch on > your code-base and the fairly large impact on users of Xfce and Unity > outweighs your concerns. I'd expect the patch to get in, particularly to GTK+ 3, where a regression like this shouldn't happen, even if it does happen to reflect a discouraged pattern. > Would you say GtkPopovers are a suitable replacement at all then for the > future or what would you advise us to migrate to? As an observer, afaics, Popovers are generally better as they act like a bog-standard container, unlike GtkMenu. Therefore, it's easier to reason about what'll happen when you start using child widgets beyond simple labels, etc. I infer that the trend from Menus toward Popovers is due to a combination of this and more appealing theming in some cases (partly due again to being a standard container).
@dboles: Thanks, that's reassuring to hear. The patch already went into Ubuntu. Regarding GtkPopovers: Yeah, those were roughly the improvements I would have expected. Unfortunately it's not so easy to do this consistently in Xfce as all panel plugins use GtkMenu by default and migrating all of them will be quite a bit of work. (And only migrating some will look and feel terrible...)
Comment on attachment 357334 [details] [review] menu: Avoid cancelling the menu on GTK+ grabs inside the GtkMenu (In reply to Simon Steinbeiss from comment #8) > @carlosg: A Xubuntu dev packaged it up in a PPA and your patch was > successfully tested. Since it's confirmed Carlos's patch fixes this regression, I doubt it's controversial to say we should land it.
Thank you devs for fixing this! You are awesome.
Thanks to you for the detailed report!