Different key map behavior compare to laptop terminal

[ziwangj]

Details

• Browser and browser version: Chrome
• OS version:
• xterm.js version: Latest

Facing different output from xterm terminal for function keys (F1->F12) compared to laptop terminal.

Steps to reproduce

1. Open xterm console
2. run script
   while true; do
   read -s -n 1 key
   echo "You typed [$key]."
   [[ $key == 'q' ]] && break
   done

echo "Quitting."

3. Type key F1, F2
   Laptop output: (macOS 13, zsh shell):
   (12:40:54) tmp $ ./reader.sh
   You typed [a].

You typed [
ou typed [[].
You typed [1].
You typed [9].
You typed [~].

You typed [
ou typed [[].
You typed [2].
You typed [9].
You typed [~].

You typed [q].
Quitting.

Xterm terminal output: will hanging in the middle for a long time without any result

[Tyriar]

If laptop differs it's probably due to the keyboard layout or browser? We pass keys through pretty consistently so not sure how this could be a problem on our end.

[ziwangj]

It is print key map behavior, somehow different than direct key press. We use standard keyboard layout. I think the root cause is https://github.com/xtermjs/xterm.js/blob/master/src/common/input/Keyboard.ts#L249C1-L249C9 print C0.ESC will cause terminal hanging

[Tyriar]

C0.ESC is how you start an escape sequence which is what the F keys are meant to do, so not sure what you mean? I haven't used the function keys much though and they're mostly inaccessible in vscode so there could be a bug here.

[jerch]

@ziwangj
C0.ESC just outputs the ESC char '\x1b' - if that creates hangs on your backend logic, something else is off there.