### System details

ThinkPad X1 Carbon Gen 12 / Intel Core Ultra 5 125U 

### What's wrong?

## Summary

When using Fcitx5 with Mozc on Omarchy Quattro, the Japanese IME candidate window is displayed at an incorrect position in native Wayland Chromium/Electron applications. The candidate window does not follow the text caret.

The issue is reproducible in both Chromium and Obsidian. It is not reproducible when either application is launched through XWayland.

Japanese input and conversion otherwise work correctly.

## Environment

- Omarchy: `4.0.0-1`
- Hardware: ThinkPad X1 Carbon Gen 12
- CPU: Intel Core Ultra 5 125U
- GPU: Intel Meteor Lake, `i915`
- Kernel: `7.1.8-arch1-3`
- Hyprland: `0.56.2-1`
- Hyprland commit: `efb50993780079460b0cbed1363e2166a2de1d9f`
- XWayland: `24.1.13`
- Session: Wayland
- Display: `1920x1200`, scale `1`
- Locale: `ja_JP.UTF-8`
- Keyboard layout: `jp106`
- Fcitx5: `5.1.21-1`
- Fcitx5 Qt: `5.1.14-1`
- Fcitx5 GTK: `5.1.7-1`
- Mozc: `3.34.6239.2-1`
- Chromium: `151.0.7922.137-1`
- Obsidian: `1.13.7-1`

Fcitx5 is managed by the stock `omarchy-fcitx5.service` and is running normally.

## Steps to reproduce

1. Start an Omarchy Quattro Wayland session.
2. Configure Fcitx5 with `keyboard-us` and Mozc.
3. Activate Mozc.
4. Launch Chromium using the standard Omarchy configuration.
5. Focus a text field, such as the Yahoo search field.
6. Type Japanese input and start conversion.
7. Move the caret or continue composing at a different position in the field.

The same behavior can be reproduced in Obsidian.

## Expected behavior

The candidate window should appear next to, or otherwise track, the text caret.

## Actual behavior

The candidate window appears at an incorrect position and does not follow the text caret. In the attached Chromium recording, the candidate list is rendered at an incorrect, relatively fixed position within the search field while Mozc conversion itself continues to work.

## A/B comparison

- Chromium running as native Wayland: **reproduces**
- Obsidian running as native Wayland: **reproduces**
- Chromium running through XWayland: **does not reproduce**
- Obsidian running through XWayland: **does not reproduce**
- The default foot terminal: candidate positioning works correctly

The XWayland workaround changes the application rendering behavior and is therefore not an ideal permanent solution.

https://github.com/user-attachments/assets/8a837abd-8468-4f8d-a26d-691ad00d8b0f

## Recording

Attached recording:

`screenrecording-2026-08-20_09-34-59.mp4`

The recording is 9.5 seconds long, 1348x306, H.264 at 60 fps.

## Relevant configuration

Chromium is configured for native Wayland:

```text
--ozone-platform=wayland
--ozone-platform-hint=wayland
```

Obsidian uses:

```text
-disable-gpu
--enable-wayland-ime
```

Fcitx5 uses:

```ini
[Behavior]
resetStateWhenFocusIn=No
```

The Fcitx5 service log reports:

```text
Using Wayland native input method protocol: 1
Loaded addon mozc
```

`fcitx5-diagnose` reports the focused foot terminal using the `wayland_v2` frontend. Fcitx5 is otherwise healthy and the Mozc addon is loaded successfully.

## Request

Could this be tracked on the Omarchy side and, if appropriate, routed to the responsible upstream project (Fcitx5, Hyprland, Chromium/Electron, or the relevant Wayland input-method integration)?

In particular, it would be useful to determine which component loses or misinterprets the caret rectangle in this configuration. A supported Wayland-native fix would be preferable to requiring users to run Chromium and Obsidian through XWayland.