Deprecating UI>OSIntegration in favor of the more generic Internals>PlatformIntegration

Can we make the hit region a bit bigger for incognito Windows?

Why would we make the hit region bigger for incognito windows?

We use the standard OS size for this region (16x16), and given that there's absolutely no visual indication that clicking here will do anything, if I were going to make changes I would be inclined to remove this entirely, not make it bigger.

I believe the report from the OP indicates that the region is smaller on incognito than it is for normal browser windows. This seems to be the case -- is it just an illusion?

AFAICT the rect is 16x16 on both.  I tested the incognito width pretty carefully just now and verified that it is 16 px wide.  If you give more details about the way you perceive it to be smaller, I'll look closely.

There's nothing in the code that's incognito-specific for this (the function in question is unaware of the window's incognito state), so I would be very surprised if the two differed.

When it is maximized in incognito, its width is significantly narrower. Like 3 pixels.
Could it be that the incognito logo is higher (in terms of z-index/z-dimension) than the hit test region or something?

A screencast is attached.
I left click every pixel or so until I get the menu.

Deleted: incognito-mode-small-width-hit-testing.webm 789 KB

	incognito-mode-small-width-hit-testing.webm 789 KB View Download

FWIW, Microsoft's tried to kill double click to close for a looooong time e.g. https://blogs.msdn.microsoft.com/jensenh/2006/06/08/you-windows-3-1-lovers/, and it's not implemented in Edge (or other UWP apps), though you can still get the menu via Alt-Space. Alt-Space is important for accessibility, and keyboard navigation usability.

I'd also be inclined to remove the double-click functionality too given that we've never had any visual indication that there's a menu there. But of course people will likely be upset, in a backspace-to-navigate sort of way.

To clarify - I hardly use this feature.
This is a be-consistent polish-level issue, not an actual pain (for me).
I do not mind if it went away altogether, but if it exists, it should be as usable in incognito mode as it is in the normal mode.

Actually, personally, I would expect the entire incognito icon to trigger the menu and not just the 16x16 corner, as it is more in line with the original Windows feature where the icon of the window would trigger the menu.

But, again, just removing the entire thing is good enough. :)

OK, there's something really weird going on.  If you keep your mouse on the top of the screen, then the incognito trigger area is indeed 16 px wide.  Just below that, it suddenly drops off in width.  Non-incognito windows don't do this.

Didn't check opaque frames, but it's definitely broken in glass.  Some kind of bug in GlassBrowserFrameView::NonClientHitTest() with how we detect HTSYSMENU.

It sort of confirms my suspicion that the image area is getting the hit instead of the non-client area. Hit testing breaks right where the image begins.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

HTSYSMENU in browser windows is gone in refresh.