1 pixel gap around window prevents mouse from interacting with control buttons (minimize, maximize, close)

[chrismarts]

Environment

Windows build number: Win32NT, 10.0.19042.0 Microsoft Windows NT 10.0.19042.0
Windows Terminal version (if applicable): 1.1.2233.0

Steps to reproduce

1. Maximize the window.
2. Move the mouse to the very top right corner of the screen and click to close the window.

Expected behavior

Correct/typical behavior (e.g. for File Explorer, Edge, UWP apps, etc...) is that the mouse interacts with the window control buttons (minimize, maximize, close) when touching the top edge of the screen, or the top right corner. Meaning, the mouse can be put into the very top right corner of the screen, and when clicking, the close button is engaged and the window closes. For the Windows Terminal, there seems to be a 1pixel "gap" along the top/sides of the window that prevents this from working.

Actual behavior

The close button does not go into a hover state with the mouse located there and the window does not close.

See example where mouse cursor is at top right corner of the screen but the close button is not "lit up" red:

I see this on some apps here and there -- Nitro PDF is another example.

[DHowett]

Repro notes: looks like it doesn't happen on 100% scale displays but it does on my 150 when I move it from my 100.

[chrismarts]

Ah great thinking. My repro/screenshot comes from a 225% scaled 4K monitor.

[chrismarts]

I'm now not seeing this in v 1.2.2381.0. Not sure if it's fixed, or whether the issue may be transient.

[itshoro]

looks like it doesn't happen on 100% scale displays

Still present for me. 100% Scaling on my display, v1.3.2382.0

[xnoreq]

Same problem here.
It happens on a secondary 1080p monitor that extends the main 1440p monitor, both 100% scaling.

The issue also exists for the tabs, see #8363.

[Don-Vito]

Same problem here.
It happens on a secondary 1080p monitor that extends the main 1440p monitor, both 100% scaling.

The issue also exists for the tabs, see #8363.

The weird part is that I am is exactly with the same setup, and cannot reproduce it no matter what 😊

[bazzilic]

I still have this issue. Could be a thing with multiple monitors with diff scaling, here are my settings:

Monitor 1

Monitor 2

[avanisubbiah]

I'm having this issue with a single 3440x1440 monitor with 100% scale.

[SpitFire-666]

I was able to replicate this issue, and managed to "fix" it.

If I maximise the window on my main monitor (LEFT, 3), all is well. If I maximise it on my secondary monitor (RIGHT, 2), the problem occurs.

Scaling is set to 100% for both monitors.

I found by "rearranging" monitor 2 to the same "height" as monitor 3, the Close button lights up now at the edge of both screens.

[KalleOlaviNiemitalo]

I have 1920×1080 on display 1, 1920×1080 on display 3 (the main display), and 1280×1024 on display 2; 100% scale in each. It was very difficult to align the top edges of the displays just right in the Settings app, which tends to snap the bottom edges instead. I was finally able to do it by dragging display 2 above display 3 and then moving it with the arrow keys. I can now click Windows Terminal tabs on each display with no gap.

If I move display 2 higher up, then displays 1 and 3 get a gap.

So, I imagine something compares the top Y coordinate of the window to 0 and not to what is in MONITORINFO.

[devhl-labs]

I have something similar. My left two monitors have the gap, and the third monitor (which is portrait) does not have the gap.

[zadjii-msft]

Okay, I finally found a configuration that works for me to repro this. For me, it's all three aligned exactly on the top, side-by-side. And it only repros on monitor 2. Weird.

---

Investigation notes:

It would seem the monitors aren't actually aligned. Monitors 1, 2, 3 are at y offsets of (0, 1, -2). interesting that maximizing works fine on 1 and 3, but not 2.

Tracing from NonClientIslandWindow::_OnNcCalcSize

maximize on	{monInfo.rcMonitor}: {originalTop} -> {newSize.top}
1	{LT(0, 0) RB(1920, 1080) [1920 x 1080]}: -8 -> 0
2	{LT(1920, 1) RB(3840, 1081) [1920 x 1080]}: -7 -> 1
3	{LT(3840, -2) RB(6096, 1502) [2256 x 1504]}: -11 -> -2

That makes me think the window is getting the right size, but maybe the xaml island isn't?

Curious. The drag bar can be clicked on the top pixel, even when the xaml elements can't. What the devil is going on here?

Got it to repro with y-offsets of [0, 0, -60] as well. Maybe the right monitor just needs to be above it?
-> YES. [0, -43, -103] also reprod on both monitors 1 and 2. Interesting.

The NCIW::MessageHandler never gets a WM_LBUTTONDOWN message in this case. That makes me thing it's either never getting sent, or it's getting sniped by the island. Nor does the top of the message pump in main.cpp. So we're not getting the mouse event there at all.

Interesting development: Teams experiences the same exact behavior. But Edgium, UWP OneNote, Sublime 4, even Hyper, none of those experience it. I wonder if we do need to keep the frame at least 1px big, even when maximized?

[devhl-labs]

Hope you can fix it. It's annoying to switch tabs and start typing commands only to find you didn't actually switch tabs.

edit - I see exactly the same gap in Teams but only in a call.

[zadjii-msft]

Okay, there's an absolute hack of a fix in 37fbeab. That's absolutely not right though. In that commit, I just move the xaml island up one pixel when we're maximized. That seems to allow the island to receive the mouse events we'd expect, but it definitely cuts off one pixel of the top of the tab row. IMO, it's not that bad, but I'd rather have the right solution. At this point I think I'm out of ideas.

@greg904 has worked in this area of code before - any ideas what might be going on here?

Also, @ocalvo and @Austin-Lamb do a lot of XAML Islands work, in case they've ever seen anything like this before.

And lastly, @ekoschik because he knows these kinds of things in and out.

[zadjii-msft]

Okay, I'm officially out of ideas now.

The top pixel of the TabViewItem's and the SplitButton is never clickable in the Terminal. Never. No idea why, but it just isn't. Not only that, but I can't repro that in the scratch app with the roughly same XAML as in the Terminal. Even when the window isn't maximized, that pixel seemingly isn't clickable for those buttons/tabs. <conjecture>I'm assuming the same is true of the MinMaxCloseControl, though that's always drawn at the full height of the titlebar, so I'm thinking that the "dead pixel" is actually up in the border pixel (when windowed), so it's not an issue.</conjecture>

[zadjii-msft]

screenshots:

enhance

As you can see, the window isn't even maximized. The split button and the tab view are aligned on the top. You can see that the pointer is pointed at a pixel that's within the bounds of the split button, but the button doesn't think it's hovered.

[ghost]

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

Handy links:

• Release Notes
• Store Download

[ghost]

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

Handy links:

• Release Notes
• Store Download