-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Comments
gnome-terminal used to suffer from this problem, too. It was super annoying. |
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! |
Well, my searching skills are apparently not up to the task ¯_(ツ)_/¯ And that should probably be /dup #522, not 552 |
This is not fixed in 0.7.3291.0 |
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. |
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. |
A bit sad this is still not fixed in 0.10.781.0 😥 |
This comment has been minimized.
This comment has been minimized.
Really hard to fix, or just keeps getting left on the backlog? |
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 |
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. :) |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
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
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)
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)
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)
🎉This issue was addressed in #10048, which has now been successfully released as Handy links: |
🎉This issue was addressed in #10048, which has now been successfully released as Handy links: |
Halleluja! |
Environment
Steps to reproduce
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.
The text was updated successfully, but these errors were encountered: