Switching pane-maximize will add an additional line break in the new window

[dhslegen]

Describe the problem:
Switching pane-maximize will add an additional line break in the new window, which can be solved by changing a shortcut key, but I'm still used to the combination of cmd option enter.

To Reproduce:
split window>cmd option enter * n

[echo304]

@Eugeny Can I take this issue?

[Eugeny]

of course!

[echo304]

@Eugeny Can you provide some advice that where all the key strokes are handled?
I suspected that predefined hotkey(cmd + option + enter) somehow affect to the terminal command line.
Reason why I think is that if I change hotkey to other key combination without 'enter' it does not add line break.

[Eugeny]

All hotkeys are handled in https://github.com/Eugeny/tabby/blob/master/tabby-core/src/services/hotkeys.service.ts , the likely solution is to preventDefault the keyboard event once a hotkey is recognized

GitHub

tabby/hotkeys.service.ts at master · Eugeny/tabby

A terminal for a more modern age. Contribute to Eugeny/tabby development by creating an account on GitHub.

[echo304]

I tried to figure out where those keyboard event is propagated in hotkeys.service.ts but it didn't work well.
I guess there is leaking(propagated) keyboard event of "Enter" somewhere... 🕵️ or somewhere around NgZone.
So, I'm going to dig where actual input is added to the UI.

tabby/tabby-terminal/src/api/baseTerminalTab.component.ts

Lines 439 to 447 in fac6ec5

	sendInput (data: string|Buffer): void {
	if (!(data instanceof Buffer)) {
	data = Buffer.from(data, 'utf-8')
	}
	this.session?.feedFromTerminal(data)
	if (this.config.store.terminal.scrollOnInput) {
	this.frontend?.scrollToBottom()
	}
	}

Is this right place to start? 🤔
@Eugeny

[Eugeny]

Not exactly, xterm is listening to keyboard events directly, so terminal input doesn't to through tabby code, but I'm intercepting all keys in HotkeyService first, where, if a key matches a known shortcut, it should be cancelled and never make it's way into xterm

[echo304]

Got it. 👍

[Issues-translate-bot]

The translator bot has detected that this issue body's language is not English, and has translated it automatically.

---

Got it. 👍

[echo304]

If I commented out these lines, this bug is removed but simply removing these lines is definitely not the solution.
I briefly understand why they are necessary thanks to the comment // macOS will swallow non-modified keyups if Cmd is held down. Can you explain the more detailed background of this code snippet?

tabby/tabby-core/src/services/hotkeys.service.ts

Lines 181 to 184 in fac6ec5

	if (process.platform === 'darwin' && eventData.metaKey && eventName === 'keydown' && !['Ctrl', 'Shift', altKeyName, metaKeyName].includes(keyName)) {
	// macOS will swallow non-modified keyups if Cmd is held down
	this.pushKeyEvent('keyup', nativeEvent)
	}

[Eugeny]

Taking these lines out won't do anything for other operating systems unfortunately, as macOS is the only one with this problem. On other OSes, keyup will still fire by itself as expected. The problem is that HotkeyService doesn't seem to intercept/cancel keyup that corresponds to a recognized shortcut, and it's getting passed down to the terminal.