[Bug]: CapsLock state becomes inverted after Super+Space + CapsLock + cursor input source switch in VirtualBox Ubuntu guest

[okachi0123-design]

Version

7.2.6

Host OS Type

Windows

Host OS name + version

Windows 11 Home 25H2 (Build 26200.8246)

Host Architecture

x86

Guest OS Type

Linux

Guest Architecture

x86

Guest OS name + version

Ubuntu 24.04.4 LTS

Component

Other

What happened?

When switching the input method using Super+Space, pressing CapsLock, and then switching the input source via cursor click, the CapsLock key behavior becomes permanently inverted until manually corrected. In the inverted state, typing without CapsLock produces uppercase, and CapsLock cannot be turned off normally.

Expected Behavior
CapsLock state should not be affected by input method switching. The modifier key state should remain consistent regardless of how the input source is changed.

Actual Behavior
CapsLock behavior becomes inverted:

• CapsLock OFF → uppercase input
• CapsLock ON → lowercase input

Additionally, CapsLock may become stuck and unable to be turned off through normal operation while in this inverted state.
Workarounds

Workaround A — Kana key reset (fixes CapsLock stuck issue only, does NOT fix inversion):
Press the カナ/かな key → CapsLock can be toggled again normally

Note: Pressing the カナ/かな key can restore CapsLock toggle functionality when CapsLock becomes stuck and cannot be turned off. However, the underlying inverted CapsLock state remains — CapsLock OFF still produces uppercase and CapsLock ON still produces lowercase.

Workaround B — Input source cycle (fixes CapsLock inversion):

1. Switch to another input source (via Super+Space or cursor)
2. Press CapsLock ON
3. Switch back to the original input source → CapsLock behavior is fully restored

Additional Notes
This is likely caused by a desynchronization between the host and guest modifier key state when VirtualBox processes the Super+Space shortcut. The Super key may not be fully released in the guest's key event queue before the input source switch occurs, leaving CapsLock in an inconsistent state. The カナ/かな key workaround suggests the issue is resolvable by triggering a different modifier path. Related to VirtualBox bug #5758, but the specific trigger sequence and workarounds appear to be new findings.

How can we reproduce this?

1. Open a VirtualBox Ubuntu guest with multiple input methods configured (e.g. Japanese + Japanese (Mozc) via IBus)
2. Press Super+Space to switch the input method
3. Press CapsLock
4. Click the input source indicator with the cursor to switch the input source
5. Observe that CapsLock is now inverted — typing without CapsLock produces uppercase characters

Did you upload all of your necessary log files, screenshots, etc.?

• Yes, I've uploaded all pertinent files to this issue.

[okachi0123-design]

Update: Additional finding regarding CapsLock stuck issue

After further testing, I found that the CapsLock stuck issue (Workaround A) may not be related to the Super+Space shortcut sequence. It can be reproduced with a different trigger:

Steps to Reproduce CapsLock stuck issue:

1. In the Ubuntu guest, ensure CapsLock is OFF (normal state)
2. Switch focus to the Windows host
3. Press CapsLock on the Windows host
4. Switch focus back to the Ubuntu guest
5. Press CapsLock ON in the Ubuntu guest
6. CapsLock becomes stuck — the LED stays on and CapsLock cannot be turned off normally

Fix: Pressing a modifier key (カナ/かな key) resolves the stuck state.

This suggests there are two separate issues:

• Issue 1 (CapsLock inversion): Caused by the Super+Space → CapsLock → cursor click sequence as originally reported. Fixed by input source cycling (Workaround B).
• Issue 2 (CapsLock stuck): Caused by host-guest CapsLock state desynchronization when switching focus. Fixed by pressing a modifier key such as カナ/かな (Workaround A).