From gtk-devel Mon Nov 20 13:04:20 2017 From: Matthias Clasen Date: Mon, 20 Nov 2017 13:04:20 +0000 To: gtk-devel Subject: Re: gtk 3 stuck menu bug on Mac Message-Id: X-MARC-Message: https://marc.info/?l=gtk-devel&m=151118307502754 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0598444687268480136==" --===============0598444687268480136== Content-Type: multipart/alternative; boundary="001a11455eac8d43e0055e69b967" --001a11455eac8d43e0055e69b967 Content-Type: text/plain; charset="UTF-8" On Sat, Nov 18, 2017 at 3:34 PM, wrote: > On Sat, Nov 18, 2017 at 6:45 AM Christian Schoenebeck < > schoenebeck@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. --001a11455eac8d43e0055e69b967 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Nov 18, 2017 at 3:34 PM, <philip.chiment= o@gmail.com> wrote:
On Sat, Nov 18, 20= 17 at 6:45 AM Christian Schoenebeck <schoenebeck@linuxsampler.org> wrote:<= br>
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:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0menu_item =3D gtk_get_event_widget ((GdkEven= t*) event);
>=C2=A0 =C2=A0 =C2=A0 =C2=A0...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0if (!GTK_IS_MENU_ITEM (menu_item) ||
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0!GTK_IS_MENU (parent))
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return false;

Looking further at this issue, the problem is probably not a timing issue l= ike
I first considered in my previous email. Fact is that the wrong widget unde= r
the mouse pointer is resolved forever whenever this issue starts to occur:<= br>
At this code location above, the gtk_menu_motion_notify() function expects<= br> 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<= br> 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 flawlessl= y on
Mac before, and since I see the Quartz implementation hasn't really cha= nged
(significantly) in the last couple years, was there some kind of important<= br> change in gtk 3 that still would need to be applied to the Quartz driver?

No-one's really maintain= ing the Quartz backend at the moment, so if you felt like investigating thi= s it would be really appreciated. You could try a 'git bisect' to s= ee what change in GTK3 might have caused the regression and that would prob= ably make it easy to see what would need to be changed in the Quartz backen= d.


As Phil= ip, 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.
--001a11455eac8d43e0055e69b967-- --===============0598444687268480136== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list --===============0598444687268480136==--