Skip to content

Eat all tab keypresses no matter what.#985

Merged
zadjii-msft merged 1 commit intomasterfrom
dev/migrie/b/744-fix-tab-navigation
May 24, 2019
Merged

Eat all tab keypresses no matter what.#985
zadjii-msft merged 1 commit intomasterfrom
dev/migrie/b/744-fix-tab-navigation

Conversation

@zadjii-msft
Copy link
Member

Summary of the Pull Request

Fix #744, by making sure the TermControl always handles Tab keypresses. This will break keyboard navigation with tab, but considering that the shell almost always wants tab as a character, this makes more sense. We should probably introduce another keybinding to manually get the focus out of the control, but that can be a follow-up.

PR Checklist

@DHowett-MSFT
Copy link
Contributor

Do we need to evaluate whether our key handler is in the right place? I'm worried about this and the Alt bell thing...

@zadjii-msft
Copy link
Member Author

The alt+bell seems to be totally out of our control. I tried eating all the alt's manually, and that doesn't seem to change anything about that path.

Is there somewhere else you're thinking about for moving our key handling to? I don't know what other place would make sense.

@binarycrusader
Copy link
Member

Only concern I would note is possible accessibility implications. As long as there's a follow-up to address the focus issue though it's probably fine?

@adiviness
Copy link
Contributor

I know for Narrator, there is a different way to navigate through elements than tab.

@zadjii-msft zadjii-msft merged commit 0f62ec8 into master May 24, 2019
@zadjii-msft zadjii-msft deleted the dev/migrie/b/744-fix-tab-navigation branch May 24, 2019 20:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Shift-Tab through powershell window goes back one command then switches outside of window

5 participants