Re: gtk 3 stuck menu bug on Mac
I uploaded a patch for this bug to the bug tracker: https://bugzilla.gnome.org/show_bug.cgi?id=791174 Since I filed this report on the "Quartz" driver component, and since I have the impression that the Quartz driver is not really maintained right now, maybe somebody else might review this patch. CU Christian On Montag, 20. November 2017 15:43:37 CET Christian Schoenebeck wrote: > Actually I have no idea where I would find those "OS X build patches". > > Anyway, I decided to be pragmatic and I am now using the attached patch to > address this Quartz driver bug on Mac. The actual root cause seems to be > that the Quartz driver does not generate crossing events correctly under > all situations (i.e when menus or tooltips appear or disappear), which in > turn causes the pointer info to reflect often an old, wrong top level > window, sometimes even NULL, which finally leads to the described symptoms > with hanging menus. Because when the current toplevel window info is > already wrong, then it is impossible for Gtk to resolve the correct child > widget that should receive pointer events. > > So the patch does not fix the Quartz driver, instead it forces to update the > pointer info very frequently instead (asking the native driver callback > always about the latest top level window). It is a suboptimal approach to > handle this issue, I know, but to be honest; in practice the user won't > feel a performance penalty, and thus I decided for myself that it does not > make sense for me to invest more days (or even weeks?) to restructure the > Quartz driver's event generation code in a way expected by Gtk3 now, just > to fix this bug in a more "clean" way from a pure theoretical point of > view. > > The rest is up to you to decide whether or whether not you might want to > apply this or a similar workaround patch to upstream Gtk. All I can say > from my side is that without addressing this issue at all, Gtk3 IMHO is not > usable on Mac, because you end up with frozen menus in a matter of few > seconds. > > CU > Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk 3 stuck menu bug on Mac
On Montag, 20. November 2017 08:04:20 CET you wrote: > >> Since this issue only seems to happen on Mac, and since it worked > >> flawlessly on > >> Mac before, and since I see the Quartz implementation hasn't really > >> changed > >> (significantly) in the last couple years, was there some kind of > >> important > >> change in gtk 3 that still would need to be applied to the Quartz driver? > > > > No-one's really maintaining the Quartz backend at the moment, so if you > > felt like investigating this it would be really appreciated. You could try > > a 'git bisect' to see what change in GTK3 might have caused the regression > > and that would probably make it easy to see what would need to be changed > > in the Quartz backend. > > As Philip, a git bisect might be helpful. But keep in mind that OS X builds > of GTK+ tend to include quite a few non-upstream patches, so keep any eye > out for those. Actually I have no idea where I would find those "OS X build patches". Anyway, I decided to be pragmatic and I am now using the attached patch to address this Quartz driver bug on Mac. The actual root cause seems to be that the Quartz driver does not generate crossing events correctly under all situations (i.e when menus or tooltips appear or disappear), which in turn causes the pointer info to reflect often an old, wrong top level window, sometimes even NULL, which finally leads to the described symptoms with hanging menus. Because when the current toplevel window info is already wrong, then it is impossible for Gtk to resolve the correct child widget that should receive pointer events. So the patch does not fix the Quartz driver, instead it forces to update the pointer info very frequently instead (asking the native driver callback always about the latest top level window). It is a suboptimal approach to handle this issue, I know, but to be honest; in practice the user won't feel a performance penalty, and thus I decided for myself that it does not make sense for me to invest more days (or even weeks?) to restructure the Quartz driver's event generation code in a way expected by Gtk3 now, just to fix this bug in a more "clean" way from a pure theoretical point of view. The rest is up to you to decide whether or whether not you might want to apply this or a similar workaround patch to upstream Gtk. All I can say from my side is that without addressing this issue at all, Gtk3 IMHO is not usable on Mac, because you end up with frozen menus in a matter of few seconds. CU Christiandiff -ruN gtk+-3.22.26.old/gdk/gdkwindow.c gtk+-3.22.26.new/gdk/gdkwindow.c --- gtk+-3.22.26.old/gdk/gdkwindow.c 2017-10-26 12:23:40.0 +0200 +++ gtk+-3.22.26.new/gdk/gdkwindow.c 2017-11-20 01:46:52.0 +0100 @@ -8531,6 +8531,26 @@ pointer_info = _gdk_display_get_pointer_info (display, device); + //HACK: workaround for a bug in the Quartz driver which causes i.e. menus to hang +#if defined(__APPLE__) + /* It seems the Quartz driver is sometimes not handling crossing events + correctly (i.e. after menu popups, tooltips appeared), which causes + toplevel_under_pointer to point to an old toplevel window or even NULL, + and finally the respective relevent child widget under the mouse pointer + could not be resolved due to this, which caused i.e. menus to ignore all + mouse events. The following is a harsh way to ensure toplevel_under_pointer + is always pointing to the window under the current pointer location by + updating this whenever pointer info is accessed. + */ + if (pointer_info) { +if (pointer_info->toplevel_under_pointer) + g_object_unref (pointer_info->toplevel_under_pointer); +GdkWindow* w = + _gdk_device_window_at_position (device, NULL, NULL, NULL, TRUE); +pointer_info->toplevel_under_pointer = w ? g_object_ref (w) : NULL; + } +#endif + if (event_window == pointer_info->toplevel_under_pointer) pointer_window = _gdk_window_find_descendant_at (event_window, ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk 3 stuck menu bug on Mac
On Sat, Nov 18, 2017 at 3:44 PM, Christian Schoenebeckwrote: > On Freitag, 17. November 2017 00:51:25 CET Christian Schoenebeck wrote: >> What I found out so far is that whenever this problem occurs, both of the >> following two checks in function gtk_menu_motion_notify() (gtkmenu.c) return >> false and the function is thus aborted at this point: >> >> menu_item = gtk_get_event_widget ((GdkEvent*) event); >> ... >> if (!GTK_IS_MENU_ITEM (menu_item) || >> !GTK_IS_MENU (parent)) >> return false; > > Looking further at this issue, the problem is probably not a timing issue like > I first considered in my previous email. Fact is that the wrong widget under > the mouse pointer is resolved forever whenever this issue starts to occur: > > At this code location above, the gtk_menu_motion_notify() function expects > menu_item to be a "GtkMenuItem" gobject class, however when this issue occurs, > menu_item is pointing at its parent "GtkMenu" gobject instead. > > I would understand if this misbehavior just happens immediately after a new > menu pops up. But whenever this stuck menu issue occurs, I can continue to > move the mouse pointer over all the visible menu items for hours and the > resolved toplevel widget under the mouse pointer (resolved by the Quartz > implementation) is always the GtkMenu widget instead of the respective > GtkMenuItem widget. > > Since this issue only seems to happen on Mac, and since it worked flawlessly > on > Mac before, and since I see the Quartz implementation hasn't really changed > (significantly) in the last couple years, was there some kind of important > change in gtk 3 that still would need to be applied to the Quartz driver? If I remember correctly I already saw that issue when I started using gtk+3 on macOS, around 3.16/18. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk 3 stuck menu bug on Mac
On Sat, Nov 18, 2017 at 3:34 PM,wrote: > On Sat, Nov 18, 2017 at 6:45 AM Christian Schoenebeck < > schoeneb...@linuxsampler.org> wrote: > >> On Freitag, 17. November 2017 00:51:25 CET Christian Schoenebeck wrote: >> > What I found out so far is that whenever this problem occurs, both of >> the >> > following two checks in function gtk_menu_motion_notify() (gtkmenu.c) >> return >> > false and the function is thus aborted at this point: >> > >> > menu_item = gtk_get_event_widget ((GdkEvent*) event); >> > ... >> > if (!GTK_IS_MENU_ITEM (menu_item) || >> > !GTK_IS_MENU (parent)) >> > return false; >> >> Looking further at this issue, the problem is probably not a timing issue >> like >> I first considered in my previous email. Fact is that the wrong widget >> under >> the mouse pointer is resolved forever whenever this issue starts to occur: >> >> At this code location above, the gtk_menu_motion_notify() function expects >> menu_item to be a "GtkMenuItem" gobject class, however when this issue >> occurs, >> menu_item is pointing at its parent "GtkMenu" gobject instead. >> >> I would understand if this misbehavior just happens immediately after a >> new >> menu pops up. But whenever this stuck menu issue occurs, I can continue to >> move the mouse pointer over all the visible menu items for hours and the >> resolved toplevel widget under the mouse pointer (resolved by the Quartz >> implementation) is always the GtkMenu widget instead of the respective >> GtkMenuItem widget. >> >> Since this issue only seems to happen on Mac, and since it worked >> flawlessly on >> Mac before, and since I see the Quartz implementation hasn't really >> changed >> (significantly) in the last couple years, was there some kind of important >> change in gtk 3 that still would need to be applied to the Quartz driver? >> > > No-one's really maintaining the Quartz backend at the moment, so if you > felt like investigating this it would be really appreciated. You could try > a 'git bisect' to see what change in GTK3 might have caused the regression > and that would probably make it easy to see what would need to be changed > in the Quartz backend. > > As Philip, a git bisect might be helpful. But keep in mind that OS X builds of GTK+ tend to include quite a few non-upstream patches, so keep any eye out for those. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk 3 stuck menu bug on Mac
On Sat, Nov 18, 2017 at 6:45 AM Christian Schoenebeck < schoeneb...@linuxsampler.org> wrote: > On Freitag, 17. November 2017 00:51:25 CET Christian Schoenebeck wrote: > > What I found out so far is that whenever this problem occurs, both of the > > following two checks in function gtk_menu_motion_notify() (gtkmenu.c) > return > > false and the function is thus aborted at this point: > > > > menu_item = gtk_get_event_widget ((GdkEvent*) event); > > ... > > if (!GTK_IS_MENU_ITEM (menu_item) || > > !GTK_IS_MENU (parent)) > > return false; > > Looking further at this issue, the problem is probably not a timing issue > like > I first considered in my previous email. Fact is that the wrong widget > under > the mouse pointer is resolved forever whenever this issue starts to occur: > > At this code location above, the gtk_menu_motion_notify() function expects > menu_item to be a "GtkMenuItem" gobject class, however when this issue > occurs, > menu_item is pointing at its parent "GtkMenu" gobject instead. > > I would understand if this misbehavior just happens immediately after a new > menu pops up. But whenever this stuck menu issue occurs, I can continue to > move the mouse pointer over all the visible menu items for hours and the > resolved toplevel widget under the mouse pointer (resolved by the Quartz > implementation) is always the GtkMenu widget instead of the respective > GtkMenuItem widget. > > Since this issue only seems to happen on Mac, and since it worked > flawlessly on > Mac before, and since I see the Quartz implementation hasn't really changed > (significantly) in the last couple years, was there some kind of important > change in gtk 3 that still would need to be applied to the Quartz driver? > No-one's really maintaining the Quartz backend at the moment, so if you felt like investigating this it would be really appreciated. You could try a 'git bisect' to see what change in GTK3 might have caused the regression and that would probably make it easy to see what would need to be changed in the Quartz backend. Regards, Philip C ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk 3 stuck menu bug on Mac
On Freitag, 17. November 2017 00:51:25 CET Christian Schoenebeck wrote: > What I found out so far is that whenever this problem occurs, both of the > following two checks in function gtk_menu_motion_notify() (gtkmenu.c) return > false and the function is thus aborted at this point: > > menu_item = gtk_get_event_widget ((GdkEvent*) event); > ... > if (!GTK_IS_MENU_ITEM (menu_item) || > !GTK_IS_MENU (parent)) > return false; Looking further at this issue, the problem is probably not a timing issue like I first considered in my previous email. Fact is that the wrong widget under the mouse pointer is resolved forever whenever this issue starts to occur: At this code location above, the gtk_menu_motion_notify() function expects menu_item to be a "GtkMenuItem" gobject class, however when this issue occurs, menu_item is pointing at its parent "GtkMenu" gobject instead. I would understand if this misbehavior just happens immediately after a new menu pops up. But whenever this stuck menu issue occurs, I can continue to move the mouse pointer over all the visible menu items for hours and the resolved toplevel widget under the mouse pointer (resolved by the Quartz implementation) is always the GtkMenu widget instead of the respective GtkMenuItem widget. Since this issue only seems to happen on Mac, and since it worked flawlessly on Mac before, and since I see the Quartz implementation hasn't really changed (significantly) in the last couple years, was there some kind of important change in gtk 3 that still would need to be applied to the Quartz driver? CU Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtk 3 stuck menu bug on Mac
Hi! I am currently investigating a menu handling bug of Gtk 3.22.26 on Mac (Quartz implementation). It happens quite often that Gtk 3 menus on Mac 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 menu simply remains stuck at this point. Has somebody looked into this issue before? What I found out so far is that whenever this problem occurs, both of the following two checks in function gtk_menu_motion_notify() (gtkmenu.c) return false and the function is thus aborted at this point: menu_item = gtk_get_event_widget ((GdkEvent*) event); ... if (!GTK_IS_MENU_ITEM (menu_item) || !GTK_IS_MENU (parent)) return false; So it seems when this misbehavior occurs, a wrong toplevel widget was assigned to the gdk event object (exactly: event->any.window->user_data). However so far I don't know the root cause yet. What looks suspicous to me though is that in gdkevents-quartz.c the toplevel widget under the pointer coordinates is resolved before the corresponding gdk event is pushed into the gdk event queue. I mean if this Quartz implementation pushes a bunch of mouse events into the gdk event queue, and one of the events i.e. would cause a new menu to popup (which always happens after pulling the events from the queue), then the previously resolved toplevel widget (in gdkevents-quartz.c) could be wrong since it resolved widgets in the past. Hints appreciated! CU Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list