#7422 may have regressed - click on the top pixel of a tab when maximized

[zadjii-msft]

From discussion on a0670cb

Interestingly, the compensation for GH #10746 might have caused 10746 to stop functioning by pushing the application body down one more pixel. I can't get the tab bar hit targets at the top of the screen when maximized to work any longer.

@DHowett If you've got a repro for that, can you fix that again? I checked out this PR when it was first opened to make sure that one was still fixed, but I guess I didn't have my monitors in the very peculiar config that repro'd #7422 in the first place.

This might also be the #11294 issue, but unlikely Dustin had the MUX commit at the time.

[sigprof]

I see a problematic behavior which does not exactly match #7422 — for me the minimize/maximize/close buttons behave normally, but anything on the tab bar (including the new tab button and the dropdown arrow) cannot be activated when clicking exactly at the top of the screen when the window is maximized. Clicks in the problem area above the tab bar seem to be completely ignored (a double click does not result in restoring the window size, a right click does not show the window menu or anything else).

System information:

• Windows Terminal Preview 1.12.2931.0
  • Note that the release version (Windows Terminal 1.11.2921.0) does not exhibit the problematic behavior — in that version clicks at the top of the screen work as expected.
• Windows 10 21H1 (19043.1348, Windows Feature Experience Pack 120.2212.3920.0)
• A single 4K monitor (Iiyama XUB2792UHSU, 3860 × 2160, scaling set to 200%)
• Task bar at the right edge of the screen (width set to minimum possible, which is 124 px in my config)

[zadjii-msft]

@kzshantonu what does your display layout look like in the Settings app, under System>Display?

[kzshantonu]

@zadjii-msft 150% scale, 2160x1440

[zadjii-msft]

Sorry, could you send me an actual screenshot of the little preview on that page? The last time this regressed, the actual alignment of the monitors was an influencing factor (which was insane). I just wanted to try and get a read if that would be an issue this time too.

[kzshantonu]

@zadjii-msft Single display

[zadjii-msft]

Welp. That's easier to set up the repro for, but alas I'm not seeing that. Any chance you've got the "auto hide taskbar" setting enabled?

[kzshantonu]

@zadjii-msft no. But I do have a vertical left taskbar, since forever

[djp101]

Windows 11 Terminal Preview 1.16.2642.0 has this issue.
Resolution: 1920x1200
Scale: 150%
Orientation: Landscape

[CactusPie]

Same issue here
Windows 10 22H2
Terminal Version: 1.15.3465.0
Resolution: 1920x1080
Scale: 150%
Orientation: Landscape
Taskbar auto-hide is NOT enabled

The problem did not occur on one of the older versions, though unfortunately I can't remember which one it was

Edit: Still occurs on version 1.16.10261.0
My environment is multi monitor, the other two monitors use the same resolution, but with 100% scale - the problem doesn't occur on the other monitors.

[djp101]

This issue also happens with the "plus" icon to open a new tab in Windows Terminal Version 1.15.3466.0, the "clickable" area should stretch up to top of the window border.

[LukeDearden]

Same issue here
Windows 10 something or other
Terminal Version: 1.17.1023
Resolution: 1920x1080
Scale: 100%
Orientation: Landscape
Taskbar auto-hide is NOT enabled

Seems like it might be related to multiple monitors and their alignment in Display settings

like this there is a tiny gap

like this seems OK

[zadjii-msft]

terminal/src/cascadia/WindowsTerminal/NonClientIslandWindow.cpp

Lines 533 to 559 in 72d0566

	void NonClientIslandWindow::_UpdateIslandPosition(const UINT windowWidth, const UINT windowHeight)
	{
	const auto originalTopHeight = _GetTopBorderHeight();
	// GH#7422
	// !! BODGY !!
	//
	// For inexplicable reasons, the top row of pixels on our tabs, new tab
	// button, and caption buttons is totally un-clickable. The mouse simply
	// refuses to interact with them. So when we're maximized, on certain
	// monitor configurations, this results in the top row of pixels not
	// reacting to clicks at all. To obey Fitt's Law, we're gonna shift
	// the entire island up one pixel. That will result in the top row of pixels
	// in the window actually being the _second_ row of pixels for those
	// buttons, which will make them clickable. It's perhaps not the right fix,
	// but it works.
	// _GetTopBorderHeight() returns 0 when we're maximized.
	const auto topBorderHeight = (originalTopHeight == 0) ? -1 : originalTopHeight;
	const til::point newIslandPos = { 0, topBorderHeight };
	winrt::check_bool(SetWindowPos(_interopWindowHandle,
	HWND_BOTTOM,
	newIslandPos.x,
	newIslandPos.y,
	windowWidth,
	windowHeight - topBorderHeight,
	SWP_SHOWWINDOW | SWP_NOACTIVATE));

If I manually change that adjustment from -1 to -2, this seems to always work. Why though? What godforsaken rounding is causing this? And is this something that's silly and needs to be like, -3 at 250% scaling?

AND

just undoing the +1 as noted in a0670cb#commitcomment-56270857 didn't seem to change this at all.

[vadimkantorov]

Just hit this again (terminal Version: 1.16.10262.0), but don't think that my UI is 150% scaled

Not only I can't click, the topmost window pixel hover even stops highlighting the tab under the mouse cursor

[gknispel-australdx]

If I understand this issue correctly it seems I'm affected by it too. I can't select tabs when the windows is maximized by clicking on the top line of the screen. I've got a 4k (3840x2400) 15.6 inches 16/10 screen configured with a scaling factor of 225%. I even thought it never worked until I recently used terminal on a low DPI screen, where it worked correctly.