fix: WCO window hover on window controls on Windows

[clavin]

Description of Change

This adds a patch to Chromium that marks non-client mouse hover events as handled so they don't get redispatched to the default OS event handler (which is currently immediately "stealing" the mouse every time it moves).

Currently, on Windows with WCO-enabled windows, Win API mouse messages first find their way to LegacyRenderWidgetHostHWND::OnMouseRange which, for non-client mouse moved events, will both handle the event normally (through HWNDMessageHandler::HandleMouseMessage which eventually bubbles down to Widget::OnMouseEvent) as well as redispatch the original message back to the OS default window procedure (via the Win API DefWndProc) on the real window handle, depending on some conditions.

Calling DefWndProc after we process a non-client area mouse move message seems to cause issues where the system will immediately send a non-client mouse exit message to the real window (HWNDMessageHandler directly this time, which again flows down to Widget::OnMouseEvent) which makes it think the mouse is no longer hovering over the non-client area.

To avoid this, an event should be marked as handled meaning LegacyRenderWidgetHostHWND will no longer forward the message to DefWndProc. Note that this is how many other mouse events behave in that method, but not hovers currently.

The only open question I haven't figured out is why DefWndProc is taking a WM_NCMOUSEMOVE message from LegacyRenderHostHWND called on HWNDMessageHandler's window handle and then sending a WM_NCMOUSELEAVE message (take note: move changed to leave) when it invokes HWNDMessageHandler's WndProc. My current thought is that we tell the system that the client area covers the full window (i.e. the window has no frame) but also indicate that the mouse is sometimes in non-client area via hit testing (which we have to do to get Snap Assist) and this sort of inconsistency might trick DefWndProc into the behavior we're seeing. Not really sure if it's worth confirming though so it might just stay a hypothesis.

In theory this shouldn't affect anything but WCO windows as usually the LegacyRenderWidgetHostHWND doesn't cover any non-client area, so I deduce that all other kinds of windows will never send the LegacyRenderWidgetHostHWND a non-client mouse message in practice.

Fixes #32360.

Checklist

• PR description included and stakeholders cc'd
• npm test passes
• PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, and past tense.

Release Notes

Notes: Fix effect when hovering over window controls on Windows in a WCO-enabled window.

[clavin]

I'm working on upstreaming this, either as-is or as a small refactor. Either way and whether it gets accepted there or not, I think it would be a good idea to land this as a patch for now rather than when it finds its way in through the roll!

[zcbenz]

Excellent fix!

[deepak1556]

Is it possible to signal the handling of this mouse event at ElectronDesktopWindowTreeHostWin layer via overriding HandleMouseEvent which acts as a delegate to HWNDMessageHandler and should help avoid the patch.

[clavin]

Good catch! I know the DesktopWindowTreeHostWin does pass along this event, so we should be able to catch it in ElectronDesktopWindowTreeHostWin and set it handled there. I'll try it and then push the change!

Also I just realized when I cleaned up the patch I broke the condition 😅 (should be != 0 instead of == 1) whoops.

[clavin]

@deepak1556 That works! It took me a minute to figure out, but as long as we do it after SendEventToSink then it works perfectly. I'll cook up a better change now.

[deepak1556]

👍

[release-clerk]

Release Notes Persisted

Fix effect when hovering over window controls on Windows in a WCO-enabled window.

[trop]

I have automatically backported this PR to "14-x-y", please check out #32716

[trop]

I have automatically backported this PR to "15-x-y", please check out #32717

[trop]

I have automatically backported this PR to "17-x-y", please check out #32719

[trop]

I have automatically backported this PR to "16-x-y", please check out #32720

[jkleinsc]

/trop run backport-to 18-x-y

[trop]

The backport process for this PR has been manually initiated - sending your PR to 18-x-y!

[trop]

I have automatically backported this PR to "18-x-y", please check out #32723