Why is the input element not behaving properly in a modal?

[manngo]

I’m working on a new package, starting from the Package Generator.

In the view, I have built a simple form which includes an input element. A simplified version includes:

constructor(serializedState) {
	this.element = document.createElement('div');
	this.element.classList.add('pulsar-tbar');

	let form = document.createElement('form');

	form.innerHTML = `
		<input name="filter" type="text"/>
		<ul id="commands"></ul>
		<button name="cancel">Cancel</button>
		<button name="ok">Add</button>
	`;

	let filter = form.querySelector('input[name="filter"]');
	filter.addEventListener('keyup', event => {
		console.log(event.key)
	});

	this.element.appendChild(form);
}

When I toggle the view the form appears, I can type in some content in the input, and the key code is output correctly in the console.

However, I can’t backspace, use the arrow keys, or do anything I can normally do with an input. I can select the whole text with the mouse and overtype, but that’s all.

Obviously something is hijacking the input. I have tried adding the input without the form, without the event listener, and using document.createElement(), and nothing helps.

Is there a fix for this?

[savetheclocktower]

In general, ordinary keyboard behavior can be restored by adding the native-key-bindings class name to a parent element.

I don't know why the Atom folks originally did it this way (making browser behavior opt-out rather than opt-in), but that's the status quo. Eventually I'd like to make this easier or at least make it more obvious what you need to do in situations like these.

[savetheclocktower]

To be fair: I have an idea of why the Atom folks originally did it this way.

Most of the application's keyboard shortcuts are defined on the workspace, not just on an editor, so they're mostly designed to work no matter what element currently has keyboard focus. On top of that, most of the workspace relies on more complex handling of common keys (like Tab and the arrow keys) than what you'd get for free from browsers.

And the robustness of what you're able to do with key sequences (not just key combinations, but sequences of key combinations) means that there needs to be some sort of “god” listener that tries to interpret every single keystroke in the app.

So if native browser handling of keyboard input were opt-out rather than opt-in, it's likely that nearly all the core packages would opt out, as would a lot of the community packages that offer user interfaces (since it's common to use a mini text-editor for single-line input rather than a basic <input type="text">).

[manngo]

it's common to use a mini text-editor for single-line input rather than a basic <input type="text">

What’s a mini text-editor? Is that one of those div.line elements I see around the interface?

[manngo]

In general, ordinary keyboard behavior can be restored by adding the native-key-bindings class name to a parent element.

Thanks for that. That also fixes another problem I was having elsewhere.

[savetheclocktower]

What’s a mini text-editor? Is that one of those div.line elements I see around the interface?

No — any single-line input from the core app is a mini-editor, meaning it inherits a lot of behavior from the full-sized editor but limits you to a single line. Examples include the find and replace fields from find-and-replace and any text field you type into from the command palette, the fuzzy finder, or the symbols view. They'll use the same font/theme settings as the larger editor and, in some scenarios (like find-and-replace in regex mode) might do some syntax highlighting, too. They keep most of the keyboard shortcuts for navigation that the larger editor has, too (like navigation by subword).

Often overkill when you're just bootstrapping a package, though!