fix(input): correct caps lock indicator state (@VardanRattan)

[VardanRattan]

Description

Fixes an issue where the Caps Lock indicator could become inverted if the page was opened while Caps Lock was already enabled.

Previously, the Caps Lock state was toggled internally on CapsLock key events, which caused incorrect initialization and desynchronization from the actual OS modifier state. This change removes the toggle-based logic and derives the Caps Lock state exclusively from KeyboardEvent.getModifierState("CapsLock"), ensuring the indicator always reflects the real modifier state after the first key event.

Checks

• Adding quotes?
  • Make sure to include translations for the quotes in the description (or another comment) so we can verify their content.
• Adding a language?
  • Make sure to follow the languages documentation
  • Add language to packages/schemas/src/languages.ts
  • Add language to exactly one group in frontend/src/ts/constants/languages.ts
  • Add language json file to frontend/static/languages
• Adding a theme?
  • Make sure to follow the themes documentation
  • Add theme to packages/schemas/src/themes.ts
  • Add theme to frontend/src/ts/constants/themes.ts
  • (optional) Add theme css file to frontend/static/themes
  • Add some screenshots of the theme, especially with different test settings (colorful, flip colors) to your pull request
• Adding a layout?
  • Make sure to follow the layouts documentation
  • Add layout to packages/schemas/src/layouts.ts
  • Add layout json file to frontend/static/layouts
• Adding a font?
  • Make sure to follow the fonts documentation
  • Add font file to frontend/static/webfonts
  • Add font to packages/schemas/src/fonts.ts
  • Add font to frontend/src/ts/constants/fonts.ts
• Check if any open issues are related to this PR; if so, be sure to tag them below.
• Make sure the PR title follows the Conventional Commits standard. (https://www.conventionalcommits.org for more info)
• Make sure to include your GitHub username prefixed with @ inside parentheses at the end of the PR title.

Closes #7472 and #5181

[Leonabcd123]

This is what we originally used, but it caused the Caps Lock warning to be stuck on Linux (see 64a0bdc).

[VardanRattan]

@Leonabcd123 Thanks for pointing that out — I looked into the Linux issue from #7195.

From what I can tell, the problem there was related to modifier state not being updated at the time the handler ran, causing the warning to remain visible until a subsequent key event.

In this change, the Caps Lock state is still derived from getModifierState("CapsLock"), but the update runs on keyup for all platforms (and additionally on keydown for macOS), which should allow the modifier state to settle correctly on Linux before being read.

I agree the toggle workaround avoided the Linux timing issue, but it also caused desynchronization when Caps Lock was already enabled on page load. If there’s a specific Linux scenario where keyup still isn’t sufficient, I’m happy to adjust the event handling further without reintroducing internal toggling.

[fehmer]

With this the caps lock warning persists when pressing caps lock on linux

[VardanRattan]

@fehmer Thanks for testing — that makes sense.
This looks like the same Linux timing issue as #7195, where the CapsLock modifier state isn’t updated at the time the event fires. I’ll update this to still derive state from getModifierState("CapsLock"), but defer the read for Linux CapsLock events so the modifier state has time to settle, instead of toggling internal state. That should clear the warning immediately without reintroducing inversion.

[fehmer]

Hi @VardanRattan , i checked the latest change, caps lock is still stuck on linux.

[VardanRattan]

Thanks for checking.

Could you share how you tested this on Linux?
Specifically:
distro + desktop environment (X11 / Wayland)
browser
whether Caps Lock was already enabled before page load, or toggled after

That’ll help narrow down whether this is the same modifier-timing issue as #7195 or a different edge case.

[fehmer]

ubuntu 25.10, gnome, wayland
chrome 144
caps was disabled on page entry.

[VardanRattan]

Thanks — that helps a lot.

Ubuntu + GNOME + Wayland + Chrome is consistent with the Linux modifier-timing issue from #7195. In that setup, getModifierState("CapsLock") can still return the previous state at the time the CapsLock key event fires, which can leave the warning stuck until another key event.

I’ll adjust the Linux handling so the CapsLock modifier read is deferred for CapsLock events, allowing the modifier state to settle before updating visibility. That should clear the warning immediately on toggle without relying on state inversion. I’ll update the PR shortly.

[fehmer]

HI @VardanRattan i checked the latest changes and it is still stuck. I think #7478 is the better approach

[VardanRattan]

@fehmer Thanks for re-testing and confirming.

If #7478 behaves correctly on Ubuntu + GNOME + Wayland + Chrome, I’m good with going that route for now. My intent here was to avoid state inversion by deferring the modifier read, but I agree practical correctness on Linux is the priority.

Happy to close this PR or rebase it later if needed.