Cannot access taskbar when terminal is maximized/fullscreen #1930

@ngudbhav commented on GitHub (Jun 25, 2019):

Same behavior this side

Windows build - 18362.175

@ngudbhav commented on GitHub (Jun 25, 2019): Same behavior this side Windows build - 18362.175

claunia commented

@FXschwartz commented on GitHub (Aug 18, 2019):

@zadjii-msft C++ is not my primary language but I would love to take a wack at this one. Can you point me in the right direction of where this would be located?

It looks like window.cpp handles creating the window and determining its size.

Off the top of your head do you have a couple of ideas of what is causing this that I could look into?

@FXschwartz commented on GitHub (Aug 18, 2019): @zadjii-msft C++ is not my primary language but I would love to take a wack at this one. Can you point me in the right direction of where this would be located? It looks like window.cpp handles creating the window and determining its size. Off the top of your head do you have a couple of ideas of what is causing this that I could look into?

claunia commented

@DHowett-MSFT commented on GitHub (Aug 18, 2019):

For Terminal you'll want to look at NonClientIslandWindow.cpp -- that one owns the window's behavior when you have the showTabsInTitlebar option turned on (default). If I recall, Chromium had a problem like this and they had to work around it somehow; there's references to checking the region of the screen that the autohiding taskbar lives in and adjusting the window frame or position by one pixel in some direction.

This comment here (warning: chromium code) seems interesting.

    // Find all auto-hide taskbars along the screen edges and adjust in by the
    // thickness of the auto-hide taskbar on each such edge, so the window isn't
    // treated as a "fullscreen app", which would cause the taskbars to
    // disappear.

@DHowett-MSFT commented on GitHub (Aug 18, 2019): For Terminal you'll want to look at NonClientIslandWindow.cpp -- that one owns the window's behavior when you have the `showTabsInTitlebar` option turned on (default). If I recall, _Chromium_ had a problem like this and they had to work around it somehow; there's references to checking the region of the screen that the autohiding taskbar lives in and adjusting the window frame or position by one pixel in some direction. This comment [here](https://chromium.googlesource.com/chromium/src.git/+/56.0.2924.87/ui/views/win/hwnd_message_handler.cc#1736) (warning: chromium code) seems interesting. ``` // Find all auto-hide taskbars along the screen edges and adjust in by the // thickness of the auto-hide taskbar on each such edge, so the window isn't // treated as a "fullscreen app", which would cause the taskbars to // disappear. ```

claunia commented

@DHowett-MSFT commented on GitHub (Aug 18, 2019):

FWIW: This is probably also the reason behind #1840

@DHowett-MSFT commented on GitHub (Aug 18, 2019): FWIW: This is probably also the reason behind #1840

claunia commented

@FXschwartz commented on GitHub (Aug 18, 2019):

@DHowett Wow thank you for the quick reply. I'll do some research/digging and see what I can find.

@FXschwartz commented on GitHub (Aug 18, 2019): @DHowett Wow thank you for the quick reply. I'll do some research/digging and see what I can find.

claunia commented

@FXschwartz commented on GitHub (Aug 19, 2019):

Ok, I've flailed for long enough.

It looks like chrome is hardcoding their taskbar height to 2px on line 215. Surely they adjust it somewhere but I don't see it.

Sounds like we need to get the taskbar height which I think can be done with GetMonitorInfo().

And then offset the size by 1px or so depending on where the taskbar is.

I cannot seem to figure out where the actual window height and width are set. The only thing I have managed to change is the margin of the window.

I know this is pretty low on the priority list but if anyone could point me to where the actual window height and width are set it would be greatly appreciated!

@FXschwartz commented on GitHub (Aug 19, 2019): Ok, I've flailed for long enough. It looks like chrome is hardcoding their taskbar height to 2px on line 215. Surely they adjust it somewhere but I don't see it. Sounds like we need to get the taskbar height which I think can be done with `GetMonitorInfo()`. And then offset the size by 1px or so depending on where the taskbar is. I cannot seem to figure out where the actual window height and width are set. The only thing I have managed to change is the margin of the window. I know this is pretty low on the priority list but if anyone could point me to where the actual window height and width are set it would be greatly appreciated!

claunia commented

@zadjii-msft commented on GitHub (Aug 19, 2019):

I'm not totally sure we set the window size manually during a WM_WINDOWPOSCHANGING. Setting the size might happen once the control returns back to the OS. Looking at the conhost code, it seems that if we want a different size than the one proposed, we need to adjust the cx and cy members of the LPWINDOWPOS in the lParam of the WM_WINDOWPOSCHANGING message. The two lines that look like what I'm talking about are here in conhost.exe

@zadjii-msft commented on GitHub (Aug 19, 2019): I'm not totally sure we set the window size manually during a WM_WINDOWPOSCHANGING. Setting the size might happen once the control returns back to the OS. Looking at the conhost code, it seems that if we want a different size than the one proposed, we need to adjust the `cx` and `cy` members of the `LPWINDOWPOS` in the `lParam` of the WM_WINDOWPOSCHANGING message. The two lines that look like what I'm talking about are [here in conhost.exe](https://github.com/microsoft/terminal/blob/master/src/interactivity/win32/windowproc.cpp#L443-L444)

claunia commented

@FXschwartz commented on GitHub (Aug 20, 2019):

@zadjii-msft I'm having trouble figuring out how that works. I've thrown some debug lines in there and I can't seem to get them to show up.

There is an OnSize function in the NonClientIslandWindow.cpp that seems to get called every time the window size changes. There is already some checks in there to see how the window size is changed (edge dragging, maximizing, etc..). What if inside the maximize check we manually adjust the screen size there, by whatever the taskbar height is?

@FXschwartz commented on GitHub (Aug 20, 2019): @zadjii-msft I'm having trouble figuring out how that works. I've thrown some debug lines in there and I can't seem to get them to show up. There is an `OnSize` function in the `NonClientIslandWindow.cpp` that seems to get called every time the window size changes. There is already some checks in there to see how the window size is changed (edge dragging, maximizing, etc..). What if inside the maximize check we manually adjust the screen size there, by whatever the taskbar height is?

claunia commented

@zadjii-msft commented on GitHub (Aug 20, 2019):

My Win32-fu isn't the best, but that sounds like it should work.

I could have sworn that WM_WINDOWPOSCHANGING lets you set the "maximized" size manually. IIRC, we're using that message right now to add some fake padding inside our window, because the OS will actually make your window bigger than the monitor.

@zadjii-msft commented on GitHub (Aug 20, 2019): My Win32-fu isn't the best, but that sounds like it _should_ work. I could have sworn that WM_WINDOWPOSCHANGING lets you set the "maximized" size manually. IIRC, we're using that message right now to add some fake padding inside our window, because the OS will actually make your window _bigger_ than the monitor.

claunia commented

@FXschwartz commented on GitHub (Aug 20, 2019):

@zadjii-msft Hmmm ok you know way more about this than I do so I will for sure spend some more time playing with WM_WINDOWPOSCHANGING to see if I can figure it out.

Really appreciate your help!

@FXschwartz commented on GitHub (Aug 20, 2019): @zadjii-msft Hmmm ok you know way more about this than I do so I will for sure spend some more time playing with WM_WINDOWPOSCHANGING to see if I can figure it out. Really appreciate your help!

claunia commented

@Fedorov113 commented on GitHub (Jan 8, 2020):

I'm experiencing this issue with the latest windows store version 0.7.3451.0.

@Fedorov113 commented on GitHub (Jan 8, 2020): I'm experiencing this issue with the latest windows store version 0.7.3451.0.

claunia commented

@DHowett-MSFT commented on GitHub (Jan 8, 2020):

@Fedorov113 thanks for the confirmation! We're pretty sure we haven't fixed this one yet, but we'll definitely close the issue when we think we have.

Feel free to subscribe with the [Subscribe] button on the right of the page.

@DHowett-MSFT commented on GitHub (Jan 8, 2020): @Fedorov113 thanks for the confirmation! We're pretty sure we haven't fixed this one yet, but we'll definitely close the issue when we think we have. Feel free to subscribe with the [Subscribe] button on the right of the page.

claunia commented

@marawannwh commented on GitHub (Feb 28, 2020):

Guys, any updates?
This is a blocker from using the app.

@marawannwh commented on GitHub (Feb 28, 2020): Guys, any updates? This is a blocker from using the app.

claunia commented