{{ message }}
Repository navigation
Linux Snap 2026.9.0: keyboard input stops working after unlock (mouse still works), 2026.8.0 unaffected #23569
Description
Steps To Reproduce
- Install/update the desktop app via Snap to 2026.9.0 (revision 171) on Ubuntu 26.04.1 (GNOME, Wayland session).
- Start Bitwarden and enter the master password on the lock screen (typing works here, vault unlocks).
- In the unlocked main view, click into the search field or any text field and try to type.
Expected Result
Keyboard input is accepted in the unlocked vault view (search field, item fields, etc.).
Actual Result
After unlocking, the app does not accept any keyboard input anymore. Only the mouse works. Typing on the lock screen works, so the problem starts with the unlocked view.
Reverting the Snap to 2026.8.0 (revision 169) with snap revert bitwarden fixes it immediately; same machine, same session, same account. So this looks like a regression between 2026.8.0 and 2026.9.0.
What we ruled out:
- Input method: launching 2026.9.0 with
XMODIFIERS=@im=none GTK_IM_MODULE= QT_IM_MODULE=(IBus bypassed) did not help. - The app ran under XWayland in both versions (
--ozone-platform=x11, display mode AUTO from the Snap launcher), so the display backend is the same for the working and the broken version.
Screenshots or Videos
No response
Additional Context
- Log lines that appear in both versions (so probably unrelated, listed for completeness): repeated
zbus::proxy: Failed to populate properties cache via GetAll ... /org/freedesktop/portal/desktop/request/...warnings about once per second, and[Credential Storage Listener] getPassword failed Error: File backend error Incorrect secret(thepassword-manager-serviceSnap interface was not connected at the time). - No error is logged at the moment keyboard input stops working; the log shows
Vault unlockedfollowed by normal list decryption. - We are holding the Snap on 2026.8.0 for now and are happy to test a fix or collect more logs.
Operating System
Linux
Operating System Version
Ubuntu 26.04.1 LTS, GNOME Shell 50.1, Wayland session, kernel 7.0.0-34-generic, snapd 2.77.1
Installation method
Snap
Build Version
2026.9.0 (Snap revision 171) broken; 2026.8.0 (Snap revision 169) works
Issue Tracking Info
- I understand that work is tracked outside of GitHub. A PR will be linked to this issue should one be opened to address it, but Bitwarden doesn't use fields like "assigned", "milestone", or "project" to track progress.
Activity
bitwarden-bot commentedon Sep 30, 2026
Thank you for reporting this issue! We've added this to our internal tracking system.
ID: PM-44302
Link (for internal use): https://bitwarden.atlassian.net/browse/PM-44302
VantixOps commentedon Sep 30, 2026
Workaround for anyone else hitting this on the Snap, until a fixed version is out:
Bitwarden has to be closed before the revert, otherwise snapd refuses with "snap has running apps". The vault itself is not touched, you just unlock again.
To undo later:
sudo snap refresh --unhold bitwarden && sudo snap refresh bitwardenUnrelated side note: on our machine the
password-manager-serviceinterface was not connected, which causes theIncorrect secretlog errors.sudo snap connect bitwarden:password-manager-servicefixes those.ant-be commentedon Sep 30, 2026
Hi there,
I am unable to reproduce this issue, it has been escalated for further investigation. If you have more information that can help us, please add it below.
Thanks!
VantixOps commentedon Oct 1, 2026
Thanks for looking into it. Some additional data that may help narrow it down, all taken from the same machine (both Snap revisions are still installed side by side):
1. Electron/Chromium did not change between the two revisions
The
bitwardenexecutable in revision 169 (2026.8.0) and revision 171 (2026.9.0) is byte-identical (cmpreports no difference). Comparing both snap directories (ignoring.pak,.soand locales), only these files differ:resources/app.asarresources/app.asar.unpacked/node_modules/@bitwarden/desktop-napi/desktop_napi.linux-x64-gnu.nodedesktop_proxymeta/snap.yaml(version bump plus the newhardware-observeplug from fix(snap): add hardware-observe plug for FIDO HID enumeration #22885)Inside
app.asarthe non-locale changes aremain.js(grew from ~4.0 MB to ~5.1 MB),preload.js,app/main.js,app/vendor.js,index.htmland368.js. So the regression should be in the app code or the native module, not in Electron, the display backend or the input method.2. Server-side feature flags of the affected account
Since the behaviour depends on the unlocked view, the account's flags may differ from your test account. US cloud, server version 2026.9.2. Flags that look relevant (from the cached server config):
Unlock is done by typing the master password.
3. Changes in 2026.9.0 that touch window/focus or unlock handling
Just as pointers, not verified: #22257 (UV reprompt and window management refactor), #22540 (new shared unlock implementation), #22227 (reuse lunr index after lock), #17764 (
desktopName/ Wayland app_id).We can switch to revision 171 again for a test run if you want a specific log level, a DevTools capture or a test build checked.
VantixOps commentedon Oct 22, 2026
Still reproducible on 2026.10.0 (Snap revision 175, latest/stable), same machine: after unlocking, the window accepts mouse clicks but no keyboard input at all.
Environment details that may help reproducing:
XDG_SESSION_TYPE=wayland)--enable-features=UseOzonePlatform --ozone-platform=x11 --no-sandbox, so it runs through XWaylanddesktop,desktop-legacy,wayland,x11,password-manager-service;hardware-observeis not connectedNote for others using the revert workaround from above: snapd only keeps two revisions, so after 2026.9.1 and 2026.10.0 were installed the working 2026.8.0 revision (169) is gone and
snap revertno longer gets you back to a working version.Happy to run a debug build or collect logs if you tell me which ones.
VantixOps commentedon Oct 22, 2026
Correction to my comment above, after more careful testing today:
One separate observation from the same testing, in case it's useful: forcing native Wayland makes the Snap crash immediately on startup (Ubuntu, Wayland session). Both
DISPLAY_MODE=WAYLAND bitwardenandbitwarden --enable-features=UseOzonePlatform --ozone-platform=waylandend with a segfault right afterExiting GPU process due to errors during initialization(kernel:bitwarden-app: segfault at 0 ... error 4 in bitwarden-app, reproducible 4/4). The default mode (XWayland,--ozone-platform=x11) runs fine.