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.

Sign up for GitHub

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

Jump to bottom

Alt-Space suppressed when Settings is the only tab #14397

Closed
danmoseley opened this issue Nov 15, 2022 · 10 comments · Fixed by #15189
Closed

Alt-Space suppressed when Settings is the only tab #14397

danmoseley opened this issue Nov 15, 2022 · 10 comments · Fixed by #15189
Labels
Area-SettingsUI Anything specific to the SUI Help Wanted We encourage anyone to jump in on these. In-PR This issue has a related PR Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Tag-Fix Doesn't match tag requirements Priority-3 A description (P3) Product-Terminal The new Windows Terminal.
Milestone
Backlog

Comments

@danmoseley
Copy link
Member

Windows Terminal version

1.15.2875.0

Windows build number

22621.819

Other Software

No response

Steps to reproduce

Open settings and close all other tabs.
Close and reopen terminal (now settings should be the only tab)
Type Alt-Space

Expected Behavior

The alt-space menu, which includes eg Close

Actual Behavior

Nothing. When settings is the only tab on startup, alt-space seems to be ignored.

This is a fairly minor bug, except it's the quickest way to close the settings and terminal with the keyboard. The only other way I know is Alt-F4. And of cousre, the menu is useful for other things like moving with the keyboard.

When settings is not the only tab open, alt-space seems to (mostly?) work. And it works on other tabs.
@danmoseley danmoseley added Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Nov 15, 2022
@DHowett
Copy link
Member

DHowett commented Nov 15, 2022

Thanks for the report! I think we actually fixed this in #14221, which should be in a coming servicing release.

/dup #14217

@ghost
Copy link

ghost commented Nov 15, 2022

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 15, 2022
@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 labels Nov 15, 2022
@DHowett
Copy link
Member

DHowett commented Nov 15, 2022

Oh, I meant #11970. I'm sorry.

@DHowett
Copy link
Member

DHowett commented Nov 15, 2022

Curious that it still repros for you...

@zadjii-msft
Copy link
Member

is the only tab

is apparently doing a lot of work in this post

@zadjii-msft zadjii-msft reopened this Nov 15, 2022
@zadjii-msft
Copy link
Member

Oh I see. THIS IS WEIRD.

If an element in the SUI has focus, then this doesn't repro. Actually, this doesn't repro if any element has focus. But in the specific case where you open the SUI, then close a terminal tab, then the focus is somewhere where alt+space isn't hooked up.

@ghost
Copy link

ghost commented Nov 16, 2022

This issue has been marked as duplicate and has not had any activity for 1 day. It will be closed for housekeeping purposes.

@ghost ghost closed this as completed Nov 16, 2022
@DHowett DHowett reopened this Nov 17, 2022
@DHowett DHowett removed the Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing. label Nov 17, 2022
@ghost ghost added the Needs-Tag-Fix Doesn't match tag requirements label Nov 17, 2022
@zadjii-msft zadjii-msft added Help Wanted We encourage anyone to jump in on these. Product-Terminal The new Windows Terminal. Priority-3 A description (P3) Area-SettingsUI Anything specific to the SUI labels Dec 2, 2022
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Dec 2, 2022
@zadjii-msft zadjii-msft added this to the Backlog milestone Dec 2, 2022
@serd2011
Copy link
Contributor

serd2011 commented Jan 18, 2023 •
edited
Loading

I also have a default profile open when I press alt+space after closing the tab and click on the titlebar.
Tested at commit 4c7879b
https://user-images.githubusercontent.com/45919738/213252168-05a796c4-326b-4c81-95e3-0ac5c64411f4.mp4

@jamespack
Copy link
Contributor

You can repro this by clicking in one of the two red lined areas.

image

@jamespack
Copy link
Contributor

for keyboard folks tabbing focus to anything on the page makes that key combo work

@jamespack jamespack mentioned this issue Apr 15, 2023
Merged
@microsoft-github-policy-service microsoft-github-policy-service bot added the In-PR This issue has a related PR label Apr 15, 2023
zadjii-msft pushed a commit that referenced this issue Apr 20, 2023
@jamespack
Default to XamlRoot when unable to find focused object (#15189)
210414e 
Default to XamlRoot when unable to find a focused object in
DirectKeyEvents

This may not be the most appropriate "fix" for this. Certainly open to
criticism and feedback. We are trapping the alt+space key chord on the
win32 side and forwarding it to the xaml side. There we try to find a
focused object by walking the xaml tree. If we are unable to find a
focused object we return false and do nothing. I suspect that the area
that has focus that prevents this from working normally is on the win32
side. Since we want to handle the system menu anyway and are explicitly
trapping that key combo and forwarding it on I thought this was the best
approach. If we cant find a focused object default to the xaml root.

## Validation Steps Performed
System menu opens as it should.

Closes #14397
@microsoft-github-policy-service microsoft-github-policy-service bot added the Needs-Tag-Fix Doesn't match tag requirements label Apr 20, 2023
DHowett pushed a commit that referenced this issue Apr 25, 2023
@jamespack @DHowett
Default to XamlRoot when unable to find focused object (#15189)
9ba0636 
Default to XamlRoot when unable to find a focused object in
DirectKeyEvents

This may not be the most appropriate "fix" for this. Certainly open to
criticism and feedback. We are trapping the alt+space key chord on the
win32 side and forwarding it to the xaml side. There we try to find a
focused object by walking the xaml tree. If we are unable to find a
focused object we return false and do nothing. I suspect that the area
that has focus that prevents this from working normally is on the win32
side. Since we want to handle the system menu anyway and are explicitly
trapping that key combo and forwarding it on I thought this was the best
approach. If we cant find a focused object default to the xaml root.

System menu opens as it should.

Closes #14397

(cherry picked from commit 210414e)
Service-Card-Id: 89001997
Service-Version: 1.17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Area-SettingsUI Anything specific to the SUI Help Wanted We encourage anyone to jump in on these. In-PR This issue has a related PR Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Tag-Fix Doesn't match tag requirements Priority-3 A description (P3) Product-Terminal The new Windows Terminal.
Projects
None yet
Milestone
Backlog
Development

Successfully merging a pull request may close this issue.

Default to XamlRoot when unable to find focused object jamespack/terminal
5 participants
@DHowett @jamespack @danmoseley @zadjii-msft @serd2011