Findings: just run gxditview on your system and click

[G. Branden Robinson]

Thanks to Robert, Nate, Tadziu, Oliver, and Dale for the replies--I
asked for help, and got it!

I'll cover the good news first.

Any system experiencing this problem can patch in a workaround (that I
have already committed to groff Git's master branch) that requires only
the editing of a text file.

Here it is:

https://git.savannah.gnu.org/cgit/groff.git/diff/src/devices/xditview/GXditview.ad?id=99a550d1e770d66894922d0e2ca7e6695435c624

This won't fix the menu, but it does make available the printing dialog,
which is the only item in the menu that didn't have a keyboard
accelerator.  The accelerator is the "p" key with any modifier pressed:
Shift, Control, Alt, or Meta.  (An unmodified "p" retreats the page
view, like PageUp.)

To see what the other accelerators are, consult the gxditview(1) man
page.

At 2023-07-27T11:54:13-0400, Robert Goulding wrote:
> I tried to do this, but gxditview was not on my system (Crostini on a
> Chromebook = Debian 11 (bullseye).
> 
> So I compiled again from source,
[...]
At 2023-07-27T12:46:29-0400, Robert Goulding wrote:
> OK, I managed to compile gxditview. Left-clicking brings up the menu;
> none of the items are selectable.

Okay, so we see the bug on Debian 11 (bullseye), now termed
"old-old-stable".  According to the Debian Package Tracking System
(PTS),[1] that release had the following X support libraries relevant to
gxditview.

libx11 2:1.6.7-1+deb10u2
libxaw 2:1.0.13-1
libxmu 2:1.1.2-2
libxt  1:1.1.5-1

At 2023-07-27T12:04:31-0500, Nate Bargmann wrote:
> I can confirm the menu is not responsive on Debian Bullseye but does
> work properly on Bookworm, at least I can select the Open and Quit
> items and get the expected result (Groff 1.22.4 on both).

That's a good enough test.

So, bullseye bad, bookworm good.

Here are the bookworm versions (oldstable):

libx11 2:1.7.2-1 (security update: 2:1.7.2-1+deb11u1)
libxaw 2:1.0.13-1.1
libxmu 2:1.1.2-2
libxt  1:1.2.0-1

libxmu stayed the same so we can probably rule that library out.

> The menu also works similarly on an up-to-date Arch Linux system
> (Groff 1.23).

"Up-to-date" is a moving target, but as of right now that appears to
mean:

libx11 1.8.6-1
libxaw 1.0.15-1
libxmu 1.1.4-1
libxt  1.3.0-1

All I can infer from this is that it seems likely that the X libraries
had this gxditview-affecting problem for a while and then fixed it.

Hrm.  I see a problem.  repology.org and the Debian Package Tracker seem
to have different ideas of which suite is which.  That's not good.

Nevertheless, as we'll see below, this source of noise in the data need
not foreclose an informed guess at the problem.

At 2023-07-27T19:05:20+0200, Tadziu Hoffmann wrote:
> gxditview from 1.22.4 freshly compiled on Opensuse 15.4 works
> (all menu items).
[...]
> Also, this is straight X11, no Wayland involved.

Great news.  If you build groff 1.23.0 there, you'll be moving faster
than official Opensuse.  ;-)

Assuming "openSUSE Leap 15.4" (repology.org's name for it) is the same
thing, I see the following package versions.

libx11 1.6.5-?
libxaw 1.0.13-?
libxmu 1.1.2-?
libxt  1.1.5-?

This is _really_ close to Debian bookworm (or whatever had libx11 1.7.2
in stable, this being the only difference among the 4 libraries)!  Apart
from vendor versioning (which repology.org doesn't put in front of you),
the only difference is in libX11, which is fundamental enough to do the
trick.  Hypothetically, libX11 grew a bug after 1.6.5 but before 1.6.7
was tagged.

At 2023-07-27T20:26:37+0200, Oliver Corff wrote:
> I tried gxditview on a Linux Fedora 38 installation (out-of-the-box,
> groff 1.22.4), everything works as expected. Left click into canvas,
> menu opens, I can select items and they behave as expected.
[...]
> I tried a second Fedora 38 box with vanilla installation, and that
> shows the problem you described.
> 
> For now, I cannot say where the problems are but I ran into library
> problems with another application, too.

Skewed field updates of package versions seem a likely explanation for
two different Fedora 38 boxes--unless both are administered rigorously
by the same person or team.  libX11 is never done getting caught with
security problems, so I'm starting to guess that what happened was that
a CVE came out, and an initial fix had undesired side effects.

But let's eyeball Fedora 38's collection of packages.

       release    updates
libx11 1.8.4-?    1.8.6-?
libxaw 1.0.14-?   n/a
libxmu 1.1.4-?    n/a
libxt  1.2.1-?    n/a

This most closely resembles Nate's up-to-date Arch Linux system.  Makes
sense since a web search tells me Fedora 38 is the current release.

There _does_ seem to have been a security update to Fedora 38's libX11
last month.

https://lwn.net/Articles/935144/

You might be well placed to see if this is a difference between your two
Fedora 38 boxes.

At 2023-07-27T22:29:23-0700, Dale Snell wrote:
> I tried this on a Fedora f33 w/XFCE (yes, I know it's old; I'm lazy)
> and groff 1.22.4.  I can start gxditroff with no trouble, but the menu
> is completely unresponsive.

Okay.  Let's get Fedora 33 into the mix.

       release    updates
libx11 1.6.12-?   1.7.2-?
libxaw 1.0.13-?   n/a
libxmu 1.1.3-?    n/a
libxt  1.2.0-?    n/a

Well, this is the same version of libX11 as security-updated Debian
bookworm (according to the PTS) or to Debian bullseye (according to
repology.org), and has the same problem.

I find myself pretty frustrated with repology's and the Debian PTS's
clashing views of what the suites are, and also with the Debian Release
Team's embrace of release code names starting with "b" for _three
releases in a row_, which is a pretty vicious trick to play on my poor
old brain with its shallow mnemonic hash buckets.

Nevertheless, the pace of X development is sufficiently glacial that I
can reach a hypothesis: libX11 went wrong for a while, and then got
fixed.

For now I will leave as an exercise for the reader a Git bisection of
libX11, with gxditview rebuilt against it and its pop-up menu tested at
each iteration.  Here's where to start.[2]

Thanks to everybody who replied for supplying enough data points for me
to rule out a groff bug.  Other frustrations aside, knowing a problem
isn't groff's fault keeps my blood pressure where the doctor wants it.

Regards,
Branden

[1] https://tracker.debian.org/pkg/$PKG
[2] https://gitlab.freedesktop.org/xorg/lib/libx11/

signature.asc
Description: PGP signature