Summary
Since upgrading to OKD 4.20, the macOS Option key no longer works as a compose key in the web console pod terminal. Special characters that require Option combinations on a German QWERTZ keyboard layout (such as \, @, {, }, [, ], ~) can no longer be entered. The same setup worked correctly on OKD 4.19.
Environment
| Field |
Value |
| OKD Version |
4.20.0-okd-scos.17 |
| Console Image |
quay.io/okd/scos-content@sha256:6a734bddf254aef6df9f64851b8175eed7b04f02a3a123f50a70bcfda945d663 |
| Operating System |
macOS |
| Keyboard Layout |
German QWERTZ (physical), set in macOS |
| Browser |
(e.g. Chrome / Safari / Firefox — reproduced across browsers) |
| Component |
OpenShift Web Console — Pod Terminal (xterm.js) |
Steps to Reproduce
- Open the OKD 4.20 web console in a browser on macOS with a German QWERTZ keyboard layout.
- Navigate to any running Pod → Terminal tab.
- Press
Option + Shift + 7 (the standard QWERTZ key combination for \).
Actual Behavior
Instead of a backslash \, the terminal outputs ^[&.
Additionally, pressing Option + 7 alone (without Shift) displays:
This confirms that xterm.js is now interpreting the Option key as a Meta/numeric-argument modifier (altIsMeta behavior) instead of passing it through to macOS as a compose key for third-level characters.
Expected Behavior
The Option key should behave as a compose key (third-level shift), consistent with macOS system behavior and the behavior in OKD 4.19. The key combination Option + Shift + 7 should produce \.
Root Cause Analysis
This regression was introduced by the xterm.js bump from an older version to 5.5.0 in PR openshift/console#15408, which was included in OKD 4.20.
xterm.js 5.x changed the default handling of the Alt/Option key. The option macOptionIsMeta (or equivalent altIsMeta) appears to now be enabled by default or its behavior has changed, causing the Option key to be treated as a Meta key rather than a macOS compose key.
On macOS QWERTZ keyboards, the following characters all rely on Option as a compose key and are therefore broken:
| Character |
QWERTZ Combination |
Broken Output |
\ |
Option + Shift + 7 |
^[& |
| |
Option + Shift + 7 (shift variant) |
broken |
@ |
Option + L |
^[l |
{ |
Option + 8 |
(arg: 8) |
} |
Option + 9 |
(arg: 9) |
[ |
Option + 5 |
(arg: 5) |
] |
Option + 6 |
(arg: 6) |
~ |
Option + N |
broken |
Additional Observations
- Switching macOS input source to ABC (US) and pressing the physical key next to
Enter (which maps to \ on US layout) does produce a backslash correctly. This confirms the issue is purely in xterm.js key event interpretation, not in the terminal backend.
- The issue is not present on the OKD 4.19 cluster running the same macOS setup.
- The system locale inside the cluster is
LANG=C.UTF-8 with no VC Keymap or X11 Layout set — this is unrelated to the issue, which originates entirely in the browser-side xterm.js key handling.
Workaround
Until a fix is available, macOS users with non-US keyboard layouts can temporarily switch their macOS input source to ABC (US) when working in the OKD web console terminal.
References
Summary
Since upgrading to OKD 4.20, the macOS
Optionkey no longer works as a compose key in the web console pod terminal. Special characters that requireOptioncombinations on a German QWERTZ keyboard layout (such as\,@,{,},[,],~) can no longer be entered. The same setup worked correctly on OKD 4.19.Environment
quay.io/okd/scos-content@sha256:6a734bddf254aef6df9f64851b8175eed7b04f02a3a123f50a70bcfda945d663Steps to Reproduce
Option + Shift + 7(the standard QWERTZ key combination for\).Actual Behavior
Instead of a backslash
\, the terminal outputs^[&.Additionally, pressing
Option + 7alone (without Shift) displays:This confirms that xterm.js is now interpreting the
Optionkey as a Meta/numeric-argument modifier (altIsMetabehavior) instead of passing it through to macOS as a compose key for third-level characters.Expected Behavior
The
Optionkey should behave as a compose key (third-level shift), consistent with macOS system behavior and the behavior in OKD 4.19. The key combinationOption + Shift + 7should produce\.Root Cause Analysis
This regression was introduced by the xterm.js bump from an older version to 5.5.0 in PR openshift/console#15408, which was included in OKD 4.20.
xterm.js 5.x changed the default handling of the
Alt/Optionkey. The optionmacOptionIsMeta(or equivalentaltIsMeta) appears to now be enabled by default or its behavior has changed, causing theOptionkey to be treated as a Meta key rather than a macOS compose key.On macOS QWERTZ keyboards, the following characters all rely on
Optionas a compose key and are therefore broken:\Option + Shift + 7^[&|Option + Shift + 7(shift variant)@Option + L^[l{Option + 8(arg: 8)}Option + 9(arg: 9)[Option + 5(arg: 5)]Option + 6(arg: 6)~Option + NAdditional Observations
Enter(which maps to\on US layout) does produce a backslash correctly. This confirms the issue is purely in xterm.js key event interpretation, not in the terminal backend.LANG=C.UTF-8with no VC Keymap or X11 Layout set — this is unrelated to the issue, which originates entirely in the browser-side xterm.js key handling.Workaround
Until a fix is available, macOS users with non-US keyboard layouts can temporarily switch their macOS input source to ABC (US) when working in the OKD web console terminal.
References