[Snap/XWayland] Fcitx5 McBopomofo IME popup is displaced from sidebar input on mixed-DPI monitors

Does this issue occur when all extensions are disabled?: Not yet established for the failing XWayland path. A separate Wayland instance with extensions disabled was tested successfully in the editor. The original failing Codex sidebar input was subsequently tested successfully with the same extension enabled after switching the real VS Code instance to Wayland.

## Environment

- VS Code: 1.136.1, commit `a44adf7f53e00964ab890f9f8758a334f1fc15bc`, x64
- Package: official Code Snap, revision 261, base core20
- OS: Ubuntu 26.04.1 LTS
- GNOME Shell: 50.1, Wayland session
- Kernel: `6.19.8-surface-3`
- Input method: Fcitx5 5.1.19 with McBopomofo (Traditional Chinese/Bopomofo)
- GNOME Input Method Panel/kimpanel: version 91
- Affected input: the message composer near the bottom-right of the Codex sidebar (extension `openai.chatgpt`, version 26.908.40401)
- `GTK_IM_MODULE=fcitx`, `QT_IM_MODULE=fcitx`, `XMODIFIERS=@im=fcitx`
- Mutter experimental features: `scale-monitor-framebuffer`, `xwayland-native-scaling`
- Insiders has not been tested.

Monitor layout in logical coordinates:

| Monitor | Resolution | Scale | Logical origin |
| --- | --- | --- | --- |
| Internal, primary | 2736 × 1824 | 200% | (272, 1080) |
| External | 1920 × 1080 | 100% | (0, 0) |

The internal monitor is positioned below the external monitor.

## Steps to reproduce

1. Use the above GNOME Wayland/mixed-DPI setup and activate McBopomofo through Fcitx5.
2. Start the official Code Snap normally from the application list.
3. Open the Codex sidebar and focus the message composer near the bottom-right of the window on the internal display.
4. Type Bopomofo to display the IME preedit/candidate popup.
5. Observe the popup position relative to the actual input caret.

## Expected

The IME popup should appear beside the actual caret and follow it, with coordinates correctly handled across monitors with different scales.

## Actual

The popup appears around the middle of the screen, far from the bottom-right input field. It can also appear on another monitor, as observed during normal use. Text input itself works.

The large displacement on the internal monitor was reproduced during troubleshooting. The application-list launch was confirmed to start with:

```text
.../code --no-sandbox --force-user-env --ozone-platform=x11
```

Fcitx5's debug information identifies this VS Code input context as `frontend:xim`, `program:code`.

## Cursor-coordinate evidence

Cursor-only D-Bus monitoring of `org.kde.impanel2.SetSpotRect` captured these values while typing in the affected input:

```text
XWayland/XIM:
x=1645, y=2885, w=0, h=0
x=1652, y=2885, w=0, h=0
```

At that time, X11 reported the Code window at root origin `(544, 2160)`, size `2736 × 1708`. The internal display's GNOME logical origin is `(272, 1080)`.

During a separate native-Wayland typing test, recorded spot rectangles included:

```text
x=1368, y=1805, w=0, h=20
x=1381, y=1805, w=0, h=20
```

These are examples from separate typing runs, not measurements at an identical character/caret position. The native-Wayland popup visually followed the caret.

The XIM numbers are consistent with a possible mix of logical coordinates within the window and physical/root coordinates for its origin. This is a hypothesis; I have not isolated whether the incorrect conversion is in Chromium/Electron, the XIM integration, or the GNOME panel.

## Verified workaround and packaging obstacle

Bypassing the Snap launcher and starting the packaged executable natively on Wayland resolved the popup displacement:

```text
--ozone-platform=wayland --enable-wayland-ime --wayland-text-input-version=3
```

The workaround was checked first in an isolated editor instance, then in the original workspace's Codex sidebar composer. The original composer popup was confirmed to appear correctly next to the caret.

There are important qualifications:

- The successful launch also used `--disable-gpu`.
- A local GNOME panel coordinate/rectangle-size workaround had been tried earlier and did **not** resolve the XWayland problem. That panel setup remained enabled during the native-Wayland comparison, so the flags alone have not been isolated as the only change.
- Directly launching this Snap binary on GNOME 50 initially failed because its bundled GTK expected legacy `antialiasing`/font keys in `org.gnome.settings-daemon.plugins.xsettings`. A local compatibility schema and the Snap's GIO modules were supplied to get the native-Wayland test running.

The installed `/snap/code/261/electron-launch` ends with:

```sh
exec "$@" --ozone-platform=x11
```

This forces normal launches back to XWayland and makes the working native-Wayland path difficult to select consistently.

## Related reports

- #329142: request to allow overriding the Snap launcher's forced X11 backend.
- #315649: related Fcitx5/caret-position symptoms, but that report concerns a fixed popup under native Wayland and says Wayland flags do not help. In this report, the failing path is the Snap's XWayland/XIM backend, and a native-Wayland launch did restore correct positioning.

Please investigate the XIM/HiDPI coordinate path and consider allowing a supported native-Wayland launch in the Snap package. If this is owned by Electron, Fcitx5, or GNOME rather than VS Code, guidance on the appropriate upstream would be appreciated.