Skip to content

Make the interactive Browser honor configured keyboard layouts - #1851

Merged
3clyp50 merged 2 commits into
agent0ai:readyfrom
Jehu:browser-keyboard-layout
Aug 27, 2026
Merged

Make the interactive Browser honor configured keyboard layouts#1851
3clyp50 merged 2 commits into
agent0ai:readyfrom
Jehu:browser-keyboard-layout

Conversation

@Jehu

@Jehu Jehu commented Aug 25, 2026

Copy link
Copy Markdown
Contributor

The interactive Browser window always ran with a US XKB layout, so non-US keyboards could not type their printed characters: German Mac users could not type @ with Option+L, and umlauts, brackets, and AltGr symbols landed on wrong keys or vanished. The Browser now applies a configured XKB layout to its private display, so typed characters match the physical keyboard.

What changed

  • New Browser settings keyboard_layout / keyboard_variant (e.g. de + mac). Values are normalized to safe XKB tokens; empty keeps the current US behavior. Layout changes flow through browser_runtime_config, so saving a new layout restarts internal runtimes, matching the existing proxy-settings semantics.
  • Browser startup applies the layout to the private Xvfb display with setxkbmap and pins it on the Xpra shadow server (--keyboard-sync=no, --keyboard-layout, --keyboard-variant), so connecting HTML5 clients cannot override the server layout.
  • The fallback canvas input path no longer discards Alt/AltGr combinations that produce printable characters; the previous code returned early on any altKey event.
  • The settings UI offers free-text layout and variant fields with a link to the official xkeyboard-config list.

Tests

  • pytest tests/test_browser_agent_regressions.py -q — 129 passed (config defaults, token normalization, restart semantics, Xpra arg generation, setxkbmap command generation, unchanged extension-path contract).
  • Manually verified on a live Dockerized runtime: with de/mac configured, Option+L types @ in the interactive Browser window; xmodmap on the private display confirms Level3 of L maps to at.

Jehu and others added 2 commits August 27, 2026 13:01
The private Browser Xvfb always started with the US XKB layout, so
non-US keyboards could not type their printed characters in the
interactive Browser window: German Mac users could not type "@" via
Option+L, and umlauts, brackets, and AltGr/Option symbols landed on
wrong keys or vanished.

Add keyboard_layout / keyboard_variant Browser settings (validated as
safe XKB tokens, empty keeps US behavior). Browser startup applies the
layout to the private display with setxkbmap and pins it on the Xpra
shadow server (--keyboard-sync=no, --keyboard-layout, --keyboard-variant)
so connecting clients cannot override the server layout. Layout changes
flow through browser_runtime_config and restart internal runtimes.

The fallback canvas input path also stopped discarding Alt/AltGr
combinations that produce printable characters, and the settings UI
offers free-text layout/variant fields linking to the official
xkeyboard-config list.
Only forward Alt-modified text from AltGraph or macOS Option input. Keep ordinary Windows and Linux Alt shortcuts from becoming literal characters, with focused regression coverage.
@3clyp50
3clyp50 force-pushed the browser-keyboard-layout branch from ffa76c0 to efb8401 Compare August 27, 2026 11:04
@3clyp50
3clyp50 changed the base branch from main to ready August 27, 2026 11:04
@3clyp50

3clyp50 commented Aug 27, 2026

Copy link
Copy Markdown
Contributor

Hi @Jehu, thank you for the contribution. I rebased the PR onto the current ready branch and added a small follow-up commit to tighten fallback canvas keyboard handling. AltGraph and macOS Option combinations that produce text are still forwarded, while ordinary Windows and Linux Alt shortcuts are no longer inserted as literal characters. I also added focused regression coverage. Merging now.

@3clyp50
3clyp50 merged commit 67dce13 into agent0ai:ready Aug 27, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants