bug#57754: 28.1; mouse menu appears in wrong location (multi-monitor)

bug#57754: 28.1; mouse menu appears in wrong location (multi-monitor)

[Grant Farnsworth]

[-- Attachment #1: Type: text/plain, Size: 4845 bytes --]

If I bring up any of the mouse menus by holding control and clicking any
mouse button, the menu appears at the far left edge of the screen instead
of where the mouse was located.

This happens in a multi-monitor setup only. If you use one monitor, or if
you use the leftmost monitor in a multi-monitor setup, the menu appears at
the mouse click location as it should.

Steps to reproduce
--------------------------------
emacs -Q
Move emacs to any monitor but the leftmost
C-mouse1

Setup
--------------------------------
* Gnome wayland 42.4
* Fedora 36 linux
* Emacs 28.1

A MacOS user told me that this bug is reproducible on that platform as
well.


In GNU Emacs 28.1 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 3.24.34,
cairo version 1.17.6)
 of 2022-07-15 built on buildhw-x86-02.iad2.fedoraproject.org
Windowing system distributor 'The X.Org Foundation', version 11.0.12201003
System Description: Fedora Linux 36 (Workstation Edition)

Configured using:
 'configure --build=x86_64-redhat-linux-gnu
 --host=x86_64-redhat-linux-gnu --program-prefix=
 --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
 --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
 --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
 --libexecdir=/usr/libexec --localstatedir=/var
 --sharedstatedir=/var/lib --mandir=/usr/share/man
 --infodir=/usr/share/info --with-dbus --with-gif --with-jpeg --with-png
 --with-rsvg --with-tiff --with-xpm --with-x-toolkit=gtk3 --with-gpm=no
 --with-xwidgets --with-modules --with-harfbuzz --with-cairo --with-json
 --with-native-compilation build_alias=x86_64-redhat-linux-gnu
 host_alias=x86_64-redhat-linux-gnu CC=gcc 'CFLAGS=-DMAIL_USE_LOCKF -O2
 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
 -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
 -Wp,-D_GLIBCXX_ASSERTIONS
 -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
 -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection'
 LDFLAGS=-Wl,-z,relro
 PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
X11 XDBE XIM XPM XWIDGETS GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads
xwidget-internal dbusbind inotify dynamic-setting system-font-setting
font-render-setting cairo move-toolbar gtk x-toolkit x multi-tty
make-network-process native-compile emacs)

Memory information:
((conses 16 68042 5875)
 (symbols 48 6647 0)
 (strings 32 19603 2438)
 (string-bytes 1 668850)
 (vectors 16 14094)
 (vector-slots 8 298869 13733)
 (floats 8 22 33)
 (intervals 56 273 0)
 (buffers 992 10))

[-- Attachment #2: Type: text/html, Size: 6248 bytes --]

bug#57754: 28.1; mouse menu appears in wrong location (multi-monitor)

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Grant Farnsworth <gvfarns@gmail.com> writes:

> If I bring up any of the mouse menus by holding control and clicking
> any mouse button, the menu appears at the far left edge of the screen
> instead of where the mouse was located.

Thanks.  Please answer the questions below:

> emacs -Q
> Move emacs to any monitor but the leftmost
> C-mouse1

Does the bug still happen if you build Emacs --with-x-toolkit=no?

> Setup
> --------------------------------
> * Gnome wayland 42.4

And if you switch to an X session?

> A MacOS user told me that this bug is reproducible on that platform as
> well.

I think this is a separate bug.

bug#57754: Update

[Grant Farnsworth]

[-- Attachment #1: Type: text/plain, Size: 429 bytes --]

Further information:

* This bug does does not present itself if I start a session under X. The
problem appears to be Wayland-specific.

* I built 28.1 from scratch with "--with-x-toolkit=no" and the bug
disappears. The menu is in the correct location, although it does not look
the same as it did.

* I built 28.1 from scratch with "--with-x-toolkit=yes" and no other
changes and the bug is back.

Thanks for looking into this!

[-- Attachment #2: Type: text/html, Size: 1131 bytes --]