GNU bug report logs - #58771
29.0.50; context submenu can not click when run emacs lucid build.

Previous Next

Package: emacs;

Reported by: Feng Shu <tumashu <at> 163.com>

Date: Tue, 25 Oct 2022 05:45:01 UTC

Severity: normal

Merged with 57320, 57518, 59733

Found in version 29.0.50

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Po Lu <luangruo <at> yahoo.com>
Cc: Feng Shu <tumashu <at> 163.com>, 58771 <at> debbugs.gnu.org
Subject: bug#58771: 29.0.50; context submenu can not click when run emacs lucid build.
Date: Wed, 26 Oct 2022 10:00:19 +0200
On Wed, 26 Oct 2022 08:42:58 +0800 Po Lu <luangruo <at> yahoo.com> wrote:

> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> I can reliably reproduce the bug, but for me it's a sympton of broader
>> buggy behavior with menus in the Lucid build, which I've observed since
>> I started regularly building with the Lucid toolkit some months ago
>> (after not doing so for many years previously, so I don't know how old
>> this behavior is).
>>
>> So while the items of a context menu (but not those of a submenu) can be
>> scrolled with the mouse, context menus are completely unresponsive to
>> keyboard events.  In contrast, with menus from the menu bar (whether
>> open via mouse click for with the F10 key binding), I can both navigate
>> and select (also in submenus) with the keyboard but other than opening
>> and closing, the menu bar menus are completely unresponsive to the
>> mouse.
>
> Could you please try to find out what this call to XtGrabPointer in
> xlwmenu.c returns when you pop up a menu?
>
> #ifdef emacs
>   x_catch_errors (display);
> #endif
>   if (XtGrabPointer ((Widget)mw, False,
>                      (PointerMotionMask
>                       | PointerMotionHintMask
>                       | ButtonReleaseMask
>                       | ButtonPressMask),
>                      GrabModeAsync, GrabModeAsync, None,
>                      mw->menu.cursor_shape,
>                      event->time) == Success) <-----------------
>     {
>       if (true
>
> If you're going to be using a debugger, then please do the debugging
> remotely from a different machine.  Otherwise, you will either lock up
> your X server or waste a lot of time when the bug simply vanishes once
> you try to debug it.
>
> Either way, we have to get this fixed before Emacs 29 is released, so
> please try to be fast here.  Thanks a lot.

I've done only elementary debugging with gdb and never from a different
machine, so I will need explicit instructions for how to set it up and
what to enter, and if it's not straightforward, I probably can't do it
soon.

But there may be a (for me) quicker way to investigate the issue: I'm in
the process of building a new system on this machine, which is an
updated version of my current system (on a different partition), and one
of the first programs I built after installing the basic system is
Emacs, first before installing X, then again with X but before
installing GTK.  On this system, the X build used the Lucid toolkit, and
with it I did not observe the menu problems I described.  Aside from
different versions of system libraries like glibc and build tools like
gcc, the two builds differ in their Emacs-specific configurations.  The
build with the menu problems used

 configure -C --with-x-toolkit=lucid --with-xinput2 CFLAGS='-Og -g3'

while the build on the newer system without the menu problems used

 configure -C --with-jpeg=ifavailable --with-gif=ifavailable --with-tiff=ifavailable

I'll try using the other configuration on the new system and see if that
makes a difference (though I probably won't get to that till this
evening.)

Steve Berman




This bug report was last modified 2 years and 132 days ago.

Previous Next


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