Prior art/User story for non-disruptive keyboard navigation

[bever1337]

Howdy! For discussion, I'm working on a project which includes multiple xtermjs terminals and other widgets on the page. One of these terminals is the primary input of the application, but users are encouraged to interact with other widgets. I do not want xtermjs's event capturing to disrupt keyboard users.

Given the simple setup:

const terminal = new Terminal();
const element = document.querySelector("#an-element-that-definitely-exists");
terminal.open(element);

Developers can listen for blur/focus events. I've seen StackOverflow posts and xtermjs github issues describing both methods below:

// textarea element created by xtermjs
terminal.textarea.addEventListener("blur", function () {});
terminal.textarea.addEventListener("focus", function () {});

terminal.element.addEventListener("blur", function () {});
terminal.element.addEventListener("focus", function () {});
// IIUC, idential to:
element.addEventListener("blur", function () {});
element.addEventListener("focus", function () {});

As the user navigates the page with keyboard and cursor, both events on both targets fire as-expected. However, once an xtermjs terminal is focused, focus becomes trapped for keyboard users, i.e. tab and shift+tab will not fire the blur event.

Looking at docs, and developers can prevent xtermjs keyboard events:

inputTerminal.attachCustomKeyEventHandler((keyboardEvent) => keyboardEvent.key !== "Tab");

At first blush, this mostly does the trick! It's not even necessary to test for the combination of shift and tab. Unfortunately, there are two layers of blurring and focusing. The user can tab between the textarea and element of the terminal which is awkward, but semi-functional. Removing the tabindex from the non-textarea might solve this issue.

I'm concerned this code is fragile. Are there other types of events that should cause blur or focus and I am still trapping them?

Are there other approaches folks have tried?

Thanks

Edits for additional observations:

• readline-addon users will observe the above solution is still not satisfactory. I think it is necessary to patch (or fork) the addon's own attachCustomKeyEventHandler callback.
• the disableStdin flag seems does not prevent xtermjs from mounting textarea element and setting tabindex=0 on the textarea and xterm elements.

[Tyriar]

I'm not sure what element that has a tabindex you're referring to? Isn't it just the textarea that can be focused?

The general question of how to handle tab and other potentially conflicting keybindings is a difficult one. You can read how VS Code handles it here: https://code.visualstudio.com/docs/terminal/advanced#_keybinding-and-the-shell. There's also "tab focus mode" (ctrl+m) which forces tab navigation in the terminal and editor.