Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clicking the current tab to raise the window should focus the text area #3609

Closed
FaffeF opened this issue Nov 17, 2019 · 22 comments · Fixed by #10048
Closed

Clicking the current tab to raise the window should focus the text area #3609

FaffeF opened this issue Nov 17, 2019 · 22 comments · Fixed by #10048
Assignees
Labels
Area-User Interface Issues pertaining to the user interface of the Console or Terminal Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-2 A description (P2) Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Milestone

Comments

@FaffeF
Copy link

FaffeF commented Nov 17, 2019

Environment

Windows build number: 10.0.18363.0
Windows Terminal version: 0.6.2951.0

Any other software? Nope

Steps to reproduce

  1. Start Terminal
  2. Focus another window
  3. Re-focus Terminal by clicking on the active tab
  4. Enter text using your keyboard

Expected behavior

Raising the Terminal window should focus the text area no matter how you do it.

Works as expected if you click any other tab than the currently active.

Actual behavior

Text input is ignored even though the Terminal window has focus. Text input is restored when clicking the text area or focusing another tab.

@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Nov 17, 2019
@egmontkob
Copy link

gnome-terminal used to suffer from this problem, too. It was super annoying.

@zadjii-msft
Copy link
Member

Thanks for the report! This is actually something that's already being tracked in #1205 / #552, and is fortunately in PR in #3540. Hopefully should be fixed in the next release.

/dup #1205
/dup #552

@ghost
Copy link

ghost commented Nov 18, 2019

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@ghost ghost closed this as completed Nov 18, 2019
@ghost ghost added Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing. and removed Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Nov 18, 2019
@FaffeF
Copy link
Author

FaffeF commented Nov 18, 2019

Well, my searching skills are apparently not up to the task ¯_(ツ)_/¯

And that should probably be /dup #522, not 552

@FaffeF
Copy link
Author

FaffeF commented Nov 26, 2019

This is not fixed in 0.7.3291.0

@zadjii-msft
Copy link
Member

AH what happened?! This definitely was fixed in a previous commit of mine. Must have somehow regressed during the PR. I'll re-open and re-investigate.

@zadjii-msft zadjii-msft reopened this Nov 26, 2019
@zadjii-msft zadjii-msft added Area-User Interface Issues pertaining to the user interface of the Console or Terminal Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-2 A description (P2) Product-Terminal The new Windows Terminal. and removed Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing. labels Nov 26, 2019
@zadjii-msft zadjii-msft added this to the Terminal-1912 milestone Nov 26, 2019
@zadjii-msft zadjii-msft self-assigned this Dec 4, 2019
@DJackman123
Copy link
Contributor

Confirming that it doesn't work for me, either. I'm on version 0.8.3651.0 of Terminal. I played around with this a bit and found that it works fine when I use Alt-Tab to make Terminal the active window. It also works when I click on the tab bar (but not a tab) of Terminal, or when I click on an inactive tab, or even the drop-down menu. It also works when using Ctrl-Tab or clicking inactive tabs when Terminal is active.
However, if I click on the active tab then focus is removed from the text area of the window. This happens regardless of whether Terminal is the active window when clicking the tab.

@FaffeF
Copy link
Author

FaffeF commented Mar 20, 2020

A bit sad this is still not fixed in 0.10.781.0 😥

@zadjii-msft

This comment has been minimized.

@FaffeF
Copy link
Author

FaffeF commented Aug 14, 2020

Really hard to fix, or just keeps getting left on the backlog?

@DHowett
Copy link
Member

DHowett commented Aug 14, 2020

@FaffeF #6290 (comment)

@zadjii-msft
Copy link
Member

Honestly a bit of both. Hard to come up with a good, comprehensive way to prevent this from regressing in the future, and also not be hard to maintain, and because of that, it just keeps getting left behind.

IIRC one of the solutions I imagined required that every UI element we add to manually do some work to do the right thing, and that's not great. Like having the cmdpal toss the focus back to the focused control isn't wrong, but it doesn't handle the search/find box appropriately. So we could do a similar thing with the tabs, presuming we fix the search box focus issue. But then also the tab color picker needs to manually toss the focus back, and the tab context menu, and the tab renamer, and anything else we might add, so that doesn't seem the most scalable

@mle-ii
Copy link

mle-ii commented Aug 14, 2020

Luckily this is not too hard to work around. I tried a few things out, so besides clicking in the terminal window area one can hit tab 2 times or click a different tab and back to the tab you want. But yeah, I've sent a few words off into the ether after clicking a tab. LOL

I suppose some other possibilities until this can get fixed without breaking things is to show that the tab UI has focus (you can see focus shown if you hit left or right arrow key when the tab has focus) and/or flash when the tab UI has focus and you type. Or perhaps when certain keys, like say alpha/numeric are hit the focus moves to the terminal and text gets sent there.

What is odd is that Ctrl+Tab cycling around through the tabs or back again with Ctrl+Shift+Tab gives the window the proper focus when is back to that tab.

And I agree, getting focus right is very hard. I spent several years of my working career at MS in my past working on testing UI controls. :)

@vefatica

This comment has been minimized.

@JFLarvoire

This comment has been minimized.

@ghost ghost closed this as completed in #10048 May 11, 2021
@ghost ghost added Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. and removed In-PR This issue has a related PR labels May 11, 2021
ghost pushed a commit that referenced this issue May 11, 2021
A redo of #6290. That PR was overkill. In that one, we'd toss focus back to the active control any time that the tab view item got focus. That's maybe not the _best_ solution.

Instead, this PR is precision strikes. We're re-using a lot of what we already have from #9260. 
* When the context menu is closed, yeet focus to the control.
* When the renamer is dismissed, yeet focus to the control.
* When the TabViewItem is tapped (meaning no one else handled it), yeet focus to the control.

### checklist 
* [x] I work here
* [ ] This is UI so it doesn't have tests
* [x] Closes #3609
* [x] Closes #5750
* [x] Closes #6680

### scenarios:

* [x] focus the window by clicking on the tab -> Control is focused. 
* [x] Open the color picker with the context menu, can move the focus inside the picker with the arrow keys.
* [x] Dismiss the picker with esc -> Control is focused. 
* [x] Dismiss the picker with enter -> Control is focused. 
* [x] Dismiss the renamer with esc -> Control is focused. 
* [x] Dismiss the renamer with enter -> Control is focused. 
* [x] Dismiss the context menu with esc -> Control is focused. 
* [x] Start renaming, then click on the tab -> Rename is committed, Control is focused. 
* [x] Start renaming, then click on the text box -> focus is still in the text box
DHowett pushed a commit that referenced this issue May 14, 2021
A redo of #6290. That PR was overkill. In that one, we'd toss focus back to the active control any time that the tab view item got focus. That's maybe not the _best_ solution.

Instead, this PR is precision strikes. We're re-using a lot of what we already have from #9260.
* When the context menu is closed, yeet focus to the control.
* When the renamer is dismissed, yeet focus to the control.
* When the TabViewItem is tapped (meaning no one else handled it), yeet focus to the control.

* [x] I work here
* [ ] This is UI so it doesn't have tests
* [x] Closes #3609
* [x] Closes #5750
* [x] Closes #6680

* [x] focus the window by clicking on the tab -> Control is focused.
* [x] Open the color picker with the context menu, can move the focus inside the picker with the arrow keys.
* [x] Dismiss the picker with esc -> Control is focused.
* [x] Dismiss the picker with enter -> Control is focused.
* [x] Dismiss the renamer with esc -> Control is focused.
* [x] Dismiss the renamer with enter -> Control is focused.
* [x] Dismiss the context menu with esc -> Control is focused.
* [x] Start renaming, then click on the tab -> Rename is committed, Control is focused.
* [x] Start renaming, then click on the text box -> focus is still in the text box

(cherry picked from commit 8564b26)
DHowett pushed a commit that referenced this issue May 14, 2021
A redo of #6290. That PR was overkill. In that one, we'd toss focus back to the active control any time that the tab view item got focus. That's maybe not the _best_ solution.

Instead, this PR is precision strikes. We're re-using a lot of what we already have from #9260.
* When the context menu is closed, yeet focus to the control.
* When the renamer is dismissed, yeet focus to the control.
* When the TabViewItem is tapped (meaning no one else handled it), yeet focus to the control.

* [x] I work here
* [ ] This is UI so it doesn't have tests
* [x] Closes #3609
* [x] Closes #5750
* [x] Closes #6680

* [x] focus the window by clicking on the tab -> Control is focused.
* [x] Open the color picker with the context menu, can move the focus inside the picker with the arrow keys.
* [x] Dismiss the picker with esc -> Control is focused.
* [x] Dismiss the picker with enter -> Control is focused.
* [x] Dismiss the renamer with esc -> Control is focused.
* [x] Dismiss the renamer with enter -> Control is focused.
* [x] Dismiss the context menu with esc -> Control is focused.
* [x] Start renaming, then click on the tab -> Rename is committed, Control is focused.
* [x] Start renaming, then click on the text box -> focus is still in the text box

(cherry picked from commit 8564b26)
DHowett pushed a commit that referenced this issue May 14, 2021
A redo of #6290. That PR was overkill. In that one, we'd toss focus back to the active control any time that the tab view item got focus. That's maybe not the _best_ solution.

Instead, this PR is precision strikes. We're re-using a lot of what we already have from #9260.
* When the context menu is closed, yeet focus to the control.
* When the renamer is dismissed, yeet focus to the control.
* When the TabViewItem is tapped (meaning no one else handled it), yeet focus to the control.

* [x] I work here
* [ ] This is UI so it doesn't have tests
* [x] Closes #3609
* [x] Closes #5750
* [x] Closes #6680

* [x] focus the window by clicking on the tab -> Control is focused.
* [x] Open the color picker with the context menu, can move the focus inside the picker with the arrow keys.
* [x] Dismiss the picker with esc -> Control is focused.
* [x] Dismiss the picker with enter -> Control is focused.
* [x] Dismiss the renamer with esc -> Control is focused.
* [x] Dismiss the renamer with enter -> Control is focused.
* [x] Dismiss the context menu with esc -> Control is focused.
* [x] Start renaming, then click on the tab -> Rename is committed, Control is focused.
* [x] Start renaming, then click on the text box -> focus is still in the text box

(cherry picked from commit 8564b26)
@ghost
Copy link

ghost commented May 25, 2021

🎉This issue was addressed in #10048, which has now been successfully released as Windows Terminal v1.8.1444.0.:tada:

Handy links:

@ghost
Copy link

ghost commented May 25, 2021

🎉This issue was addressed in #10048, which has now been successfully released as Windows Terminal Preview v1.9.1445.0.:tada:

Handy links:

@FaffeF
Copy link
Author

FaffeF commented May 25, 2021

Halleluja!

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-User Interface Issues pertaining to the user interface of the Console or Terminal Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-2 A description (P2) Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Projects
None yet
10 participants