[BUG]: Noctalia lock screen crashes/disconnects on niri when fcitx5 IM popup/state UI is triggered

[NewSunH]

Submission checklist

• I have searched existing issues and confirmed this is not a duplicate.
• I am using the latest available version of Noctalia.

Bug description

Noctalia lock screen reliably breaks on niri when fcitx5 is running and an input-method UI event should be shown while the session is locked.

This is not just an invisible candidate window. When the issue is triggered, niri reports that the session-lock client disconnected/died, then
enters a dead-lock/red-screen state. The session remains locked, but the Noctalia lock screen client is gone.

The issue is 100% reproducible on my setup. It happens whenever fcitx5 would normally show an input-method related popup/state UI on the lock
screen, for example:

• typing letters while a Chinese/Rime input method is active
• pressing Shift
• pressing CapsLock

Shift/CapsLock are enough to reproduce because they normally trigger fcitx5 input-method switching/status UI.

Steps to reproduce

1. Start a niri session with Noctalia shell running.

2. Start fcitx5 with Rime / Chinese input enabled.

3. Switch the active input method to Chinese/Rime.

4. Lock the screen through Noctalia:

   noctalia-shell ipc call lockScreen lock

In my niri config this is bound to a lock-screen script, but the important part is that Noctalia's lock screen is used.

5. While the screen is locked, press a key that causes fcitx5 to show IM UI:
   • type a letter when using Rime / Chinese before lock, or
   • press Shift, or
   • press CapsLock.

Expected behavior

The lock screen should keep running and should accept password input normally.

If input-method UI cannot be displayed on the lock screen, it should be suppressed or ignored safely. It should not kill or disconnect the session-
lock client.

Actual behavior

The Noctalia/Quickshell lock screen client disconnects or dies. niri then reports a dead session-lock client and shows a red/dead-lock screen.

From the logs, niri itself does not crash. The problem appears to be the lock screen client dying while the session is locked.

Logs / error output

This is from one reproduction on 2026-05-16.

  fcitx5 and Rime were running before locking:

  2026-05-16T10:30:01+08:00 systemd[3096]: Started Fcitx 5.
  2026-05-16T10:30:01+08:00 systemd[3096]: Started app-niri-noctalia-shell-3313.scope.
  2026-05-16T10:30:02+08:00 fcitx5[3320]: Loaded addon rime
  2026-05-16T10:30:08+08:00 fcitx5[3320]: Wayland self diagnose information
  2026-05-16T10:30:08+08:00 fcitx5[3320]: Using Wayland native input method protocol: 1
  2026-05-16T10:30:08+08:00 fcitx5[3320]: GTK_IM_MODULE=fcitx
  2026-05-16T10:30:08+08:00 fcitx5[3320]: QT_IM_MODULE=fcitx


  Then the lock screen is started and niri reports that the lock client disconnected:

  2026-05-16T10:30:18+08:00 systemd[3096]: Started app-niri-lock-screen-4618.scope.
  2026-05-16T10:30:18+08:00 niri[3242]: locking session
  2026-05-16T10:30:20+08:00 niri[3242]: error in client communication (pid 3313)


  After that, every attempt to lock again replaces an existing dead lock:

  2026-05-16T10:30:25+08:00 niri[3242]: locking session (replacing existing dead lock)
  2026-05-16T10:30:29+08:00 niri[3242]: error in client communication (pid 4789)
  2026-05-16T10:30:31+08:00 niri[3242]: locking session (replacing existing dead lock)
  2026-05-16T10:30:32+08:00 niri[3242]: error in client communication (pid 5278)
  2026-05-16T10:30:39+08:00 niri[3242]: locking session (replacing existing dead lock)
  2026-05-16T10:30:40+08:00 niri[3242]: error in client communication (pid 5780)


  Finally, the session can unlock after another quickshell process handles authentication:

  2026-05-16T10:30:46+08:00 quickshell[6602]: pam_kwallet5(login:auth): pam_sm_authenticate
  2026-05-16T10:30:46+08:00 quickshell[6602]: gkr-pam: unlocked login keyring
  2026-05-16T10:30:47+08:00 niri[3242]: unlocking session

Compositor

Niri

Distribution

NixOS

Environment information

- OS: NixOS 26.05.20260510.da5ad66 (Yarara)
  - Kernel: Linux 7.0.5-zen1 x86_64
  - Compositor: niri 26.04 (Nixpkgs)
  - Noctalia: noctalia-shell 4.7.6 (nixpkgs: https://github.com/NixOS/nixpkgs/commit/f13f4d9c6f8e2d0dd4a00480282ec9cc1c16663b)
  - Input method: fcitx5 5.1.19
  - fcitx5 addons in use include:
      - Rime
      - Wayland frontend
      - classicui
      - kimpanel
      - imselector
      - notifications
  - fcitx5 diagnostics report:

    Using Wayland native input method protocol: 1
    GTK_IM_MODULE=fcitx
    QT_IM_MODULE=fcitx

Additional context

When niri is showing the red/dead-lock screen, the compositor is still responsive enough to handle my locked-session shortcut. I have Mod+Escape
configured with allow-when-locked=true to run my Noctalia lock command again.

Pressing Mod+Escape from the red/dead-lock screen starts the Noctalia lock screen again. niri logs this as:

locking session (replacing existing dead lock)

This suggests that niri itself is still running and input shortcuts still work. The failed component appears to be the current Noctalia/Quickshell
session-lock client, which disconnects/dies after fcitx5 input-method popup/status UI is triggered.

[Ly-sec]

Thanks so much for reaching out and sharing this with us!

Right now, our team is entirely focused on building v5. Since the v4 lifecycle has officially come to an end, we are wrapping up old issues and won’t be shipping any further updates or fixes to that codebase.

We are closing this issue for now, but we truly appreciate you taking the time to report it. We aren’t quite ready to open up the v5 tracker for public bug reports or feature requests just yet, but we’ll definitely keep your feedback in mind as we develop the new version!

Cheers!