Bug#1151025: nautilus: crashes with "Error 71 (Protocol error) dispatching to Wayland display" when touching on-screen keyboard key in rename dialog

[=?gb2312?B?RmVsaXggWGluZyjQ0K1Vx78p?=]

Package: nautilus
Version: 48.3-2
Severity: important
Tags: a11y

Dear Maintainer,

On a touchscreen-only ARM device, Nautilus crashes with a Wayland protocol
error the moment the user touches any key on the GNOME on-screen keyboard
(OSK) inside the rename dialog. The rename feature is therefore completely
unusable on touchscreen devices.

Steps to reproduce (100% reproducible):

1. Enable the screen keyboard:
   gsettings set org.gnome.desktop.a11y.applications screen-keyboard-enabled true
   (it is enabled by default on touchscreen-only devices)
2. Take a screenshot, open Files (Nautilus) and locate the image
3. Long-press the image -> choose "Rename" -> dialog opens, OSK appears
4. Touch any key on the OSK

Expected result: the character is typed into the rename entry.

Actual result: Nautilus dies immediately, dialog and OSK disappear:

  Apr 14 23:12:40.323977 nautilus[17269]: Error 71 (Protocol error)
  dispatching to Wayland display.

The crash correlates exactly with the touch event: evtest recorded the
touch on the OSK key at 23:12:40.199, the process died 124 ms later.
The input layer was verified clean (no spurious key events from the
touchscreen or other input devices).

Environment:

  Debian 13.6 (trixie), aarch64
  nautilus 48.3-2, gnome-shell 48.7-0+deb13u2 (Wayland session),
  libmutter-16-0 48.7-0+deb13u1, libgtk-4-1 4.18.6+ds-2,
  libadwaita-1-0 1.7.6-1~deb13u1
  Kernel 6.1.118-rt36 (vendor kernel, RK3576 SoC, Mali-G52 GPU)
  8 inch MIPI touchscreen (Goodix capacitive)

Additional information:

Repeated "Unable to register the application: GDBus.Error:...
NoReply: Message recipient disconnected from message bus without
replying" messages from nautilus precede the crash on every
interaction.

The system has systemd-coredump not installed; I can provide a
WAYLAND_DEBUG=1 trace or a backtrace with debug symbols if needed.

Same behavior was observed on a second device (different SoC, same
Debian trixie GNOME 48 stack), so this does not look hardware-specific.