Public bug reported: [Impact]
Users with two or more input sources configured, where a non-Latin layout is among them (e.g. `us` + `ua`, or `us` + `ru`), cannot reliably enter their password on the lock screen. If the screen locks while the non-Latin source is active, the unlock dialog comes up in that layout. The user presses Super+Space to switch to the Latin layout and starts typing — and after one or a few characters the input source flips back to the non-Latin one on its own. The password is submitted wrong and authentication fails. It typically takes several attempts before a switch sticks and the unlock succeeds. The cause is in `InputSourceManager` in `js/ui/status/keyboard.js`. When focus enters a password field, IBus emits a `set-content-type` signal with purpose `PASSWORD`; the shell then enters a mode where IBus engines are temporarily disabled and snapshots the most-recently-used input source list into `_mruSourcesBackup`. A layout switch made by the user in that state updates the live `_mruSources` list but leaves the backup untouched, and the write-back to the `mru-sources` GSettings key is suppressed for the duration. When the matching non-PASSWORD content-type event arrives, the shell restores the stale backup and activates its head — reverting to the layout that was active before the user's switch. The event that triggers the restore is itself produced by the layout switcher popup stealing key focus from the entry. It returns through ibus-daemon over two D-Bus hops, so it arrives a few hundred milliseconds later, after the popup has already been destroyed. That is why the revert appears to happen "while typing": no code path reacts to keystrokes, the delayed event simply lands while the user is entering the first characters. Whether a given switch survives depends on which timing window it falls into, which is why the problem is intermittent and eventually resolves after several tries. This was fixed upstream in GNOME Shell by commit 8e0f850ed, "status/keyboard: Preserve MRU order while IBus is disabled", which syncs the backup on interactive source switches. It is present in GNOME Shell 50.0 and was backported upstream to the 48.8 and 49.5 stable releases. It was never backported to the gnome-46 branch, so Ubuntu 24.04 LTS is still affected. Upstream bug: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8538 Upstream fix: https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/4101 Duplicate report describing the lock-screen symptom: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8617 [Test Plan] On an up-to-date Ubuntu 24.04 LTS desktop install (either Xorg or Wayland; the bug is not session-type specific): 1. Open Settings → Keyboard → Input Sources and add a second, non-Latin source alongside English (US) — for example Ukrainian. Leave "Input Sources" set to be shared across all windows (`gsettings get org.gnome.desktop.input-sources per-window` should report `false`, which is the default). 2. Switch the active input source to Ukrainian with Super+Space. 3. Lock the screen with Super+L and wake it to get the unlock dialog. The layout indicator shows Ukrainian. 4. Press Super+Space to switch to English (US). Confirm the indicator changes. 5. Click into the password entry and type the password one character at a time, pausing roughly half a second between characters, watching the indicator. Expected result: the layout stays on English (US) for the whole password, and the password is accepted on the first attempt. Actual result without the fix: after one to a few characters the indicator flips back to Ukrainian on its own and the remaining characters are entered in the wrong layout, so authentication fails. Repeating steps 4-5 is needed, sometimes several times, before the switch holds. Repeat the sequence at least five times, since the failure is timing-dependent and an individual attempt can pass by chance. A related, non-disruptive check that exercises the same code path without locking the session: with Ukrainian active, run `pkexec true` to get a shell-drawn password dialog, press Super+Space to switch to English (US), and type slowly into the entry. The same revert occurs. Regression check for the mixed-IBus case, if an IBus engine is available: configure English (US) plus an IBus input method (e.g. Japanese Mozc), confirm that focusing a password entry still falls back out of the IBus engine, and that the source chosen while the password entry is focused is the one active after focus leaves it. [Where problems could occur] The change is a 12-line upstream cherry-pick confined to `InputSourceManager._currentInputSourceChanged()` and its single call site in `activateInputSource()` in `js/ui/status/keyboard.js`. It adds a parameter to a private method that has exactly one caller, and adds one guarded block that runs only when all three of the following hold: the activation was interactive, IBus is currently in the temporarily-disabled state, and a backup MRU list exists. Non-interactive activations — the ones performed internally during `reload()` and keymap reapplication — are explicitly excluded, so the restore order is not perturbed by the shell's own bookkeeping. Outside that state the code path is unchanged, so ordinary layout switching, the panel input-source menu, and per-window input sources (`org.gnome.desktop.input-sources per-window true`) behave exactly as before. The plausible failure mode, if the fix were wrong, would be the MRU order in `org.gnome.desktop.input-sources mru-sources` ending up in an unexpected sequence after using a password field, which would show up as Super+Space cycling to the wrong source. That is user-visible and would be caught by the test plan above. There is no risk to authentication itself: the change touches only which keyboard layout is active, never the credential handling. The same patch has been in production upstream since GNOME Shell 48.8, 49.5 and 50.0 without follow-up regression reports. [Other Info] The fix is a straight cherry-pick of upstream commit 8e0f850edc03ada8f79ef68412eabb05c5f76d02 with no adaptation beyond context: the surrounding `_currentInputSourceChanged()` body differs slightly between 46.0 and current main (46.0 reorders the MRU list with a splice loop, main uses a spread), but the added block is byte-identical to upstream. GNOME Shell 46 and 47 are end-of-life upstream, so there is no upstream stable branch to backport this through; it has to be carried as a distro patch. A debdiff against gnome-shell 46.0-0ubuntu6~24.04.14 is attached. ** Affects: gnome-shell (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 noble sru -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2163564 Title: Lock screen keyboard layout reverts while the password is being typed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/2163564/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
