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 786029 - clicking on gtk-slider makes the parent disappear
clicking on gtk-slider makes the parent disappear
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
3.22.x
Other Linux
: Normal major
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2017-08-09 05:29 UTC by KN
Modified: 2017-08-28 18:11 UTC
See Also:
GNOME target: ---
GNOME version: 3.21/3.22


Attachments
slider (21.17 KB, image/png)
2017-08-09 05:29 UTC, KN
  Details
menu: Avoid cancelling the menu on GTK+ grabs inside the GtkMenu (1.00 KB, patch)
2017-08-10 10:17 UTC, Carlos Garnacho
committed Details | Review

Description KN 2017-08-09 05:29:43 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.
Comment 1 Timm Bäder 2017-08-09 06:52:52 UTC
The only commit that could affect GtkScale is https://git.gnome.org/browse/gtk+/commit/?h=gtk-3-22&id=9b032073cbcf5aadbeb4b74f0cf662a9fa5f5530 afaics
Comment 2 KN 2017-08-09 12:41:09 UTC
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?
Comment 3 KN 2017-08-09 12:45:50 UTC
I must add, when I use my mouse scroll to change the slider value, it works perfectly (the overlay doesn't disappear).
Comment 4 KN 2017-08-10 09:12:39 UTC
@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) ?
Comment 5 Carlos Garnacho 2017-08-10 10:17:37 UTC
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.
Comment 6 Carlos Garnacho 2017-08-10 10:35:57 UTC
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.
Comment 7 Matthias Clasen 2017-08-10 12:19:38 UTC
Using ranges inside menus is really not a supportable (or supported) configuration.
Comment 8 Simon Steinbeiss 2017-08-20 17:47:48 UTC
@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.)
Comment 9 Simon Steinbeiss 2017-08-20 17:48:48 UTC
In case anyone wonders, the PPA is to be found here: https://launchpad.net/~xubuntu-dev/+archive/ubuntu/xubuntu-staging/+packages
Comment 10 Emmanuele Bassi (:ebassi) 2017-08-20 17:53:49 UTC
(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.
Comment 11 Simon Steinbeiss 2017-08-20 22:21:57 UTC
@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?
Comment 12 Daniel Boles 2017-08-24 08:54:37 UTC
(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).
Comment 13 Simon Steinbeiss 2017-08-25 16:54:10 UTC
@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 14 Daniel Boles 2017-08-27 19:47:46 UTC
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.
Comment 15 KN 2017-08-28 17:58:54 UTC
Thank you devs for fixing this! You are awesome.
Comment 16 Daniel Boles 2017-08-28 18:11:26 UTC
Thanks to you for the detailed report!