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 791174 - gtk+ 3.22.26 [patch]: Hanging/stuck menus on macOS
gtk+ 3.22.26 [patch]: Hanging/stuck menus on macOS
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Backend: Quartz
3.22.x
Other Mac OS
: Normal major
: ---
Assigned To: gtk-quartz maintainers
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2017-12-03 19:03 UTC by Christian Schoenebeck
Modified: 2018-05-02 19:31 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gtk3 event handling fix for Quartz backend (macOS) (1.44 KB, patch)
2017-12-03 19:03 UTC, Christian Schoenebeck
none Details | Review
1st revision of original patch (1.39 KB, patch)
2017-12-08 16:28 UTC, Christian Schoenebeck
none Details | Review

Description Christian Schoenebeck 2017-12-03 19:03:01 UTC
Created attachment 364863 [details] [review]
gtk3 event handling fix for Quartz backend (macOS)

There is a severe bug in the gtk+ 3 Quartz backend which causes menus on Mac to stop processing any mouse events.

So when that happens, i.e. menu items are no more highlighted when moving the mouse pointer over them, nor do the menu items fire when being clicked, nor does i.e. a submenu close when moving the pointer over another toplevel menu node. The respective menu simply remains stuck at this point. This applies to application menus as well as to all other ones like popup menus for instance. Since this is a general problem with the Quartz event handling, it might even effect the behavior of other widgets as well.

The attached patch against gtk+ 3.22.26 fixes this event handling issue for macOS.

For more information about this issue, please refer to the following discussion:

https://mail.gnome.org/archives/gtk-devel-list/2017-November/msg00010.html

Please note that without addressing this issue at all, IMHO I find Gtk+3 not being usable on Mac at all. It seems this issue was introduced very early between the Gtk2 and Gtk3 release points. So it already exists for a very long time now.
Comment 1 Paul Davis 2017-12-08 14:37:54 UTC
The #ifdef here should not be __APPLE__. It needs to be conditional on the windowing system being quartz. The core of GDK will be built on MacOS for the X Window backend as well as the Quartz one.
Comment 2 Christian Schoenebeck 2017-12-08 16:28:27 UTC
Created attachment 365258 [details] [review]
1st revision of original patch

Sure! Are you fine with this new compile time conditional, or do you even want an additional runtime driver type check here as well?
Comment 3 Matthias Clasen 2017-12-09 20:24:31 UTC
I would much prefer to find a fix that does not need a backend-specific #ifdef in the frontend code.
Comment 4 Christian Schoenebeck 2017-12-09 21:25:20 UTC
Of course. But this behavior has to be injected there.

One could add a new function callback to the driver API instead, but most probably you would not like that solution either.
Comment 5 GNOME Infrastructure Team 2018-05-02 19:31:54 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/986.