Windows-up does not maximize window when using Focus and Hide title bar #23344

claunia commented

@jamespack commented on GitHub (Jun 7, 2025):

This works on windows 11. I noticed you're not passing any args. Did you try passing --focus to it?

We have nearly the same build number.

@jamespack commented on GitHub (Jun 7, 2025): This works on windows 11. I noticed you're not passing any args. Did you try passing --focus to it? We have nearly the same build number.

claunia commented

@chipbite commented on GitHub (Jun 8, 2025):

Hi James! Thanks alot for reading!

This works on windows 11.

No, this is win 11.
I suspect you misunderstand: Windows build number 10.0.26100.4061 is windows 11, 24H2.
(win 11 build nrs are seemingly above 20000, I am guessing, so 10.0.20000+ is no longer win10, it seems. There are many resources on build numbers, example)).

I noticed you're not passing any args. Did you try passing --focus to it?

I am not sure I understand this comment. I have windows terminal configured to focus mode being always on (paragraph 3, here). And that works, it starts in focus mode. Passing the same thing as a parameter seems redundant, not sure if that would give any better view of the problem?

We have nearly the same build number.

Right, see my comment above. I suspect alot of people assume that the major version 10.0 = win 10, which is certainly not unreasonable. In fact several different windows OS products share major version 10.0.

Anyway, the behavior is totally consistent om my machine. I suspect to repro, the key elements are to have focus mode setup, etc. I suspect reproducing should be straightforward, will try on a few other machines later in the next work week.

@chipbite commented on GitHub (Jun 8, 2025): Hi James! Thanks alot for reading! > This works on windows 11. No, this is win 11. I suspect you misunderstand: Windows build number 10.0.26100.4061 _is_ windows 11, 24H2. (win 11 build nrs are seemingly above 20000, I am guessing, so 10.0.20000+ is no longer win10, it seems. There are many resources on build numbers, [example](https://www.gaijin.at/en/infos/windows-version-numbers))). >I noticed you're not passing any args. Did you try passing --focus to it? I am not sure I understand this comment. I have windows terminal configured to focus mode being always on (paragraph 3, [here](https://learn.microsoft.com/en-us/windows/terminal/tips-and-tricks#focus-mode)). And that works, it starts in focus mode. Passing the same thing as a parameter seems redundant, not sure if that would give any better view of the problem? > We have nearly the same build number. Right, see my comment above. I suspect alot of people assume that the major version 10.0 = win 10, which is certainly not unreasonable. In fact several different windows OS products share major version 10.0. Anyway, the behavior is totally consistent om my machine. I suspect to repro, the key elements are to have focus mode setup, etc. I suspect reproducing should be straightforward, will try on a few other machines later in the next work week.

claunia commented

@jamespack commented on GitHub (Jun 11, 2025):

Thanks for teaching me how to default to Focus mode! Thats pretty dope. Unfortunately, it still works for me :(

Im not confused about build numbers. I was simply stating our build numbers are close and I am on Windows 11 and it works. Sorry for the confusion.

@jamespack commented on GitHub (Jun 11, 2025): Thanks for teaching me how to default to Focus mode! Thats pretty dope. Unfortunately, it still works for me :( Im not confused about build numbers. I was simply stating our build numbers are close and I am on Windows 11 and it works. Sorry for the confusion.

claunia commented

https://github.com/user-attachments/assets/a157436c-aa83-49ab-bba9-f61abeb89b67

@jamespack commented on GitHub (Jun 11, 2025):

Working Build

OS: 10.26100.4202
Terminal: 1.22.11141.0
Not sure if these will be helpful for the team but just in case.

@jamespack commented on GitHub (Jun 11, 2025): ### Working Build OS: 10.26100.4202 Terminal: 1.22.11141.0 Not sure if these will be helpful for the team but just in case. https://github.com/user-attachments/assets/a157436c-aa83-49ab-bba9-f61abeb89b67

claunia commented

@mawid6 commented on GitHub (Jun 11, 2025):

Thanks for checking it out! Odd that you cant reproduce, I wonder what the secret ingredient is.

I found a workaround, which is to use the good old alt-space, x chord. It seems to work fine, but win-up does not, for me...

@mawid6 commented on GitHub (Jun 11, 2025): Thanks for checking it out! Odd that you cant reproduce, I wonder what the secret ingredient is. I found a workaround, which is to use the good old `alt-space, x` chord. It seems to work fine, but `win-up` does not, for me...

claunia commented

@DHowett commented on GitHub (Jun 11, 2025):

Hmm. While we try to figure out what the underlying issue is, I have a few questions:

Are you using any shell extensions that change windowing behavior? Replace the taskbar/?
Does F11 or Alt+Enter work to kick the window into fullscreen (though I recognize that this is more maximized than you'd like)

FWIW: We can't reproduce this here, even on 10.0.26100 🙂

Though, while trying to reproduce it I did manage to make a window that doesn't respond to Win+Up or Win+Down at all, but still responds to Win+Left/Right. Huh.

@DHowett commented on GitHub (Jun 11, 2025): Hmm. While we try to figure out what the underlying issue is, I have a few questions: - Are you using any shell extensions that change windowing behavior? Replace the taskbar/? - Does <kbd>F11</kbd> or <kbd>Alt+Enter</kbd> work to kick the window into fullscreen (though I recognize that this is more maximized than you'd like) FWIW: We can't reproduce this here, even on 10.0.26100 🙂 Though, while trying to reproduce it I did manage to make a window that doesn't respond to Win+Up or Win+Down at all, but still responds to Win+Left/Right. Huh.

claunia commented

@chipbite commented on GitHub (Jun 15, 2025):

Hi!

* Are you using any shell extensions that change windowing behavior? Replace the taskbar/?

No, I dont think so. I use powertoys but have disabled all the windowing related tools.

* Does F11 or Alt+Enter work to kick the window into fullscreen (though I recognize that this is more maximized than you'd like)

Yes, they work. As I said above, so does e g alt-space + x chord.

FWIW: We can't reproduce this here, even on 10.0.26100 🙂

I will try and see if I can repro on some colleagues computers tomorrow.

Though, while trying to reproduce it I did manage to make a window that doesn't respond to Win+Up or Win+Down at all, but still responds to Win+Left/Right. Huh.

Odd. For me it is just that win-up consistently moves the half-screen-width window to the top-half, making it quarter screen sized, as the screen-capture above shows.

@chipbite commented on GitHub (Jun 15, 2025): Hi! > * Are you using any shell extensions that change windowing behavior? Replace the taskbar/? No, I dont think so. I use powertoys but have disabled all the windowing related tools. > * Does F11 or Alt+Enter work to kick the window into fullscreen (though I recognize that this is more maximized than you'd like) Yes, they work. As I said above, so does e g `alt-space + x` chord. > FWIW: We can't reproduce this here, even on 10.0.26100 🙂 I will try and see if I can repro on some colleagues computers tomorrow. > Though, while trying to reproduce it I did manage to make a window that doesn't respond to Win+Up or Win+Down at all, but still responds to Win+Left/Right. Huh. Odd. For me it is just that `win-up` consistently moves the half-screen-width window to the top-half, making it quarter screen sized, as the screen-capture above shows.

claunia commented

@jamespack commented on GitHub (Jun 16, 2025):

Odd. For me it is just that win-up consistently moves the half-screen-width window to the top-half, making it quarter screen sized, as the screen-capture above shows.

Oh.. I think that's the default behavior. At least that's what I see from half size If you hit the key chord again does it maximize?

@jamespack commented on GitHub (Jun 16, 2025): > Odd. For me it is just that `win-up` consistently moves the half-screen-width window to the top-half, making it quarter screen sized, as the screen-capture above shows. Oh.. I think that's the default behavior. At least that's what I see from half size If you hit the key chord again does it maximize?

claunia commented

@chipbite commented on GitHub (Jun 16, 2025):

Odd. For me it is just that win-up consistently moves the half-screen-width window to the top-half, making it quarter screen sized, as the screen-capture above shows.

Oh.. I think that's the default behavior. At least that's what I see from half size If you hit the key chord again does it maximize?

Yes - I meant subsequent win-up presses, not the initial one.
The initial win-up press moves the window to the top half, which is correct and as expected, as you note.

This can be seen in the screencapture above, i e:
All subsequent win-up presses do nothing.

~~I will clarify this in the text of the post!~~

I have clarified the repro in the post, to be clear on this!

Thanks!

@chipbite commented on GitHub (Jun 16, 2025): > > Odd. For me it is just that `win-up` consistently moves the half-screen-width window to the top-half, making it quarter screen sized, as the screen-capture above shows. > > Oh.. I think that's the default behavior. At least that's what I see from half size If you hit the key chord again does it maximize? Yes - I meant _subsequent_ `win-up` presses, not the initial one. The initial `win-up` press moves the window to the top half, which is correct and as expected, as you note. This can be seen in the screencapture above, i e: All subsequent `win-up` presses do nothing. ~~I will clarify this in the text of the post!~~ I have clarified the repro in the post, to be clear on this! Thanks!

claunia commented

@jamespack commented on GitHub (Jun 16, 2025):

Thx for clarifying.

@jamespack commented on GitHub (Jun 16, 2025): Thx for clarifying.

claunia commented

@Philipp01105 commented on GitHub (Jul 10, 2025):

Tested it on my Machine (10.0.26100.4349) and is also not reproduceable

@Philipp01105 commented on GitHub (Jul 10, 2025): Tested it on my Machine (10.0.26100.4349) and is also not reproduceable

claunia commented