GNU bug report logs - #59733
29.0.50; unrespnsive Xaw menus

Previous Next

Full log

Message #40 received at 59733 <at> debbugs.gnu.org (full text, mbox):

From: Madhu <enometh <at> meer.net>
To: luangruo <at> yahoo.com
Cc: 59733 <at> debbugs.gnu.org
Subject: Re: bug#59733: 29.0.50; unresponsive Xaw menus
Date: Mon, 05 Dec 2022 13:35:09 +0530 (IST)

*  Po Lu <87mt83r7xw.fsf <at> yahoo.com>
Wrote on Sun, 04 Dec 2022 14:36:59 +0800
> If XtGrabPointer returns a non-zero value, then it means obtaining the
> grab failed.  Exactly which non-zero value does it return?  Do the menus
> start working if you comment out the call to "XtGrabPointer" entirely?
>
> The relevant return codes are:
>
>         #define GrabSuccess		0
>         #define AlreadyGrabbed		1
>         #define GrabInvalidTime		2
>         #define GrabNotViewable		3
>         #define GrabFrozen		4
>
>> PS (can the typo in the Subject line be fixed)
>
> Yes, as long as you keep the "bug#" intact.

Thanks, unfortunately this looks like a genuine heisenbug and my
earlier reports should be deemed unreliable.  I do have builds which
"don't work" but I'm am now unable to produce *new* builds which
"don't work", (say with adding printf debugging or resetting)

AFAICT both XtGrabPointer and XtGrabKeyboard return Success in all
cases (both "works" and "doesn't work" builds) - keyboard and pointer
are both grabbed as expected - from gdb dprintfs, disassembly seems
identical.

The only significant thing I can report (I have libinput
enable-tab=true) on a "doesn't work" build is that if i quickly make
two single taps on the help button on the toolbar, on the touchpad,
then the pop-up-menu "works".  (the effect seems to be an event
between the activation of the menu and the display of the menu - F10
doesn't work as usual). There hasn't been any progress Sorry

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.