Bisect does indeed point at the CL from #0.

You are probably looking for a change made after 544787 (known good), but no later than 544788 (first known bad).
CHANGELOG URL:https://chromium.googlesource.com/chromium/src/+log/cd54fed5e109370d5dd84d59e01819c1b786aefd..979c3c4d8355e456339c648db65c8201991b43af

Yeah, this is probably related to my patch.

When ShouldCustomDrawSystemTitlebar is enabled, when the user clicks on the Minimize button, the backing Windows10CaptionButton goes from state 1 (Hover) to state 2 (Down). OnMouseExited then fires and sets the button's State from 2 to 0 (Normal). The button is not repainted on the now-minimized window; you can see the button is still in the "Pressed" mode in the thumbnail screenshot exposed in Windows' Alt+Tab or Taskbar hover.

When the user subsequently task-switches back to Chrome, WindowEventDispatcher::OnWindowBoundsChanged calls PostSynthesizeMouseMove which posts a task to run SynthesizeMouseMoveEvent, which appears to generate a fake mouse event using the last captured mouse location, which was over the Minimize button. Chrome thus thinks that the user's mouse is over the Minimize button, and changes its state back to 1 (Hover) which results in Windows10CaptionButton::OnPaintBackground painting the button as if it were hovered.

 Issue 829325  has been merged into this issue.

#7: Thanks for the analysis. That's more complicated that I expected. Do you know why this doesn't reproduce for other buttons?

Re #9: It's entirely possible that there's something simpler I've missed, or a simple fix. For instance, I don't understand at all why OnWindowBoundsChanged calls PostSynthesizeMouseMove.

> Do you know why this doesn't reproduce for other buttons? 

Not exactly, although if I change the Maximize button so that it minimizes the frame, it gets "stuck" in the same way when clicked.

 if (sender == maximize_button_)
   // frame()->Maximize();
   frame()->Minimize();    // Shenanigans!

#10: I meant for other non-caption buttons, like the tab close-x. But in testing, if I hover the minimize button but use windows+down arrow to minimize (instead of clicking) the bug doesn't reproduce. Interesting!

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a6885b5355fb39feb35c3b8e3431963e0c3ba703

commit a6885b5355fb39feb35c3b8e3431963e0c3ba703
Author: Bret Sepulveda <bsep@chromium.org>
Date: Fri Apr 13 20:00:35 2018

Fix custom titlebar minimize button stuck hovered when clicked.

Normally when a button is clicked we assume the mouse is still hovering
over it, so we go back to the hovered state and wait for the mouse exit
event. However, when the minimize button minimizes the window Windows
gives us the mouse exit event before the mouse up event, so the button
will get stuck in the hovered state.

This patch fixes this by resetting the button state when it receives
a window control action, the same way the opaque frame currently solves
this problem.

Bug:  828591 
Change-Id: I6e3f27b8f92bcbf3fb8171555702b8cf5326ba21
Reviewed-on: https://chromium-review.googlesource.com/1006373
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Bret Sepulveda <bsep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#550733}
[modify] https://crrev.com/a6885b5355fb39feb35c3b8e3431963e0c3ba703/chrome/browser/ui/views/frame/glass_browser_frame_view.cc
[modify] https://crrev.com/a6885b5355fb39feb35c3b8e3431963e0c3ba703/chrome/browser/ui/views/frame/glass_browser_frame_view.h
[modify] https://crrev.com/a6885b5355fb39feb35c3b8e3431963e0c3ba703/ui/views/win/hwnd_message_handler.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7a7c85f7eff9c6b597782e00ffad7d20fe3dfc55

commit 7a7c85f7eff9c6b597782e00ffad7d20fe3dfc55
Author: Dirk Pranke <dpranke@chromium.org>
Date: Sat Apr 14 01:23:43 2018

Revert "Fix custom titlebar minimize button stuck hovered when clicked."

This reverts commit a6885b5355fb39feb35c3b8e3431963e0c3ba703.

Reason for revert: Speculatively reverting to see if it fixes the failure for AutomationApiTest.CloseTab is failing in site_per_process_browser_tests on Linux Tests (dbg)(1); see  crbug.com/833011  and https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Linux%20Tests%20%28dbg%29%281%29/71426

Original change's description:
> Fix custom titlebar minimize button stuck hovered when clicked.
> 
> Normally when a button is clicked we assume the mouse is still hovering
> over it, so we go back to the hovered state and wait for the mouse exit
> event. However, when the minimize button minimizes the window Windows
> gives us the mouse exit event before the mouse up event, so the button
> will get stuck in the hovered state.
> 
> This patch fixes this by resetting the button state when it receives
> a window control action, the same way the opaque frame currently solves
> this problem.
> 
> Bug:  828591 
> Change-Id: I6e3f27b8f92bcbf3fb8171555702b8cf5326ba21
> Reviewed-on: https://chromium-review.googlesource.com/1006373
> Reviewed-by: Scott Violet <sky@chromium.org>
> Commit-Queue: Bret Sepulveda <bsep@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#550733}

TBR=sky@chromium.org,bsep@chromium.org

Change-Id: I2809f8bbc666dd87b9a696eb87935cb3bd0f5e7c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug:  828591 
Reviewed-on: https://chromium-review.googlesource.com/1012476
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Dirk Pranke <dpranke@chromium.org>
Cr-Commit-Position: refs/heads/master@{#550847}
[modify] https://crrev.com/7a7c85f7eff9c6b597782e00ffad7d20fe3dfc55/chrome/browser/ui/views/frame/glass_browser_frame_view.cc
[modify] https://crrev.com/7a7c85f7eff9c6b597782e00ffad7d20fe3dfc55/chrome/browser/ui/views/frame/glass_browser_frame_view.h
[modify] https://crrev.com/7a7c85f7eff9c6b597782e00ffad7d20fe3dfc55/ui/views/win/hwnd_message_handler.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b9ac15055efa2c182e93c519e6ce5b2d808116e0

commit b9ac15055efa2c182e93c519e6ce5b2d808116e0
Author: Dirk Pranke <dpranke@chromium.org>
Date: Sat Apr 14 04:10:51 2018

Reland "Fix custom titlebar minimize button stuck hovered when clicked."

This reverts commit 7a7c85f7eff9c6b597782e00ffad7d20fe3dfc55.

Reason for revert: This doesn't seem to have been the problem. I'm now guessing that https://crrev.com/c/996458 was the problem, because that was in the original blamelist, and was reverted, and the test stopped failing when that was reverted, but not this CL.

Original change's description:
> Revert "Fix custom titlebar minimize button stuck hovered when clicked."
> 
> This reverts commit a6885b5355fb39feb35c3b8e3431963e0c3ba703.
> 
> Reason for revert: Speculatively reverting to see if it fixes the failure for AutomationApiTest.CloseTab is failing in site_per_process_browser_tests on Linux Tests (dbg)(1); see  crbug.com/833011  and https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Linux%20Tests%20%28dbg%29%281%29/71426
> 
> Original change's description:
> > Fix custom titlebar minimize button stuck hovered when clicked.
> > 
> > Normally when a button is clicked we assume the mouse is still hovering
> > over it, so we go back to the hovered state and wait for the mouse exit
> > event. However, when the minimize button minimizes the window Windows
> > gives us the mouse exit event before the mouse up event, so the button
> > will get stuck in the hovered state.
> > 
> > This patch fixes this by resetting the button state when it receives
> > a window control action, the same way the opaque frame currently solves
> > this problem.
> > 
> > Bug:  828591 
> > Change-Id: I6e3f27b8f92bcbf3fb8171555702b8cf5326ba21
> > Reviewed-on: https://chromium-review.googlesource.com/1006373
> > Reviewed-by: Scott Violet <sky@chromium.org>
> > Commit-Queue: Bret Sepulveda <bsep@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#550733}
> 
> TBR=sky@chromium.org,bsep@chromium.org
> 
> Change-Id: I2809f8bbc666dd87b9a696eb87935cb3bd0f5e7c
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug:  828591 
> Reviewed-on: https://chromium-review.googlesource.com/1012476
> Reviewed-by: Dirk Pranke <dpranke@chromium.org>
> Commit-Queue: Dirk Pranke <dpranke@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#550847}

TBR=sky@chromium.org,dpranke@chromium.org,bsep@chromium.org

Change-Id: I24d630ab51c665b9df680cdcdbfd0ffe5a1b4fe7
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug:  828591 
Reviewed-on: https://chromium-review.googlesource.com/1013268
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Dirk Pranke <dpranke@chromium.org>
Cr-Commit-Position: refs/heads/master@{#550878}
[modify] https://crrev.com/b9ac15055efa2c182e93c519e6ce5b2d808116e0/chrome/browser/ui/views/frame/glass_browser_frame_view.cc
[modify] https://crrev.com/b9ac15055efa2c182e93c519e6ce5b2d808116e0/chrome/browser/ui/views/frame/glass_browser_frame_view.h
[modify] https://crrev.com/b9ac15055efa2c182e93c519e6ce5b2d808116e0/ui/views/win/hwnd_message_handler.cc

Able to reproduce the issue using chrome reported version #67.0.3387.0.

Verified the fix on Win-10 using Chrome version #68.0.3398.0 as per the comment #0.
Attaching screen cast for reference.
Observed that buttons only showed as hovered when hovered.
Hence, the fix is working as expected. 
Adding the verified labels.

Thanks...!!

Deleted: 828591.mp4 1006 KB

	828591.mp4 1006 KB View Download

I can still reproduce this problem in 68.0.3398.0 (Official Build) canary (64-bit) (cohort: Clang-64) on Windows 10.

Deleted: ReproIn683398.png 23.5 KB

	ReproIn683398.png 23.5 KB View Download

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a6885b5355fb39feb35c3b8e3431963e0c3ba703

commit a6885b5355fb39feb35c3b8e3431963e0c3ba703
Author: Bret Sepulveda <bsep@chromium.org>
Date: Fri Apr 13 20:00:35 2018

Fix custom titlebar minimize button stuck hovered when clicked.

Normally when a button is clicked we assume the mouse is still hovering
over it, so we go back to the hovered state and wait for the mouse exit
event. However, when the minimize button minimizes the window Windows
gives us the mouse exit event before the mouse up event, so the button
will get stuck in the hovered state.

This patch fixes this by resetting the button state when it receives
a window control action, the same way the opaque frame currently solves
this problem.

Bug:  828591 
Change-Id: I6e3f27b8f92bcbf3fb8171555702b8cf5326ba21
Reviewed-on: https://chromium-review.googlesource.com/1006373
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Bret Sepulveda <bsep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#550733}
[modify] https://crrev.com/a6885b5355fb39feb35c3b8e3431963e0c3ba703/chrome/browser/ui/views/frame/glass_browser_frame_view.cc
[modify] https://crrev.com/a6885b5355fb39feb35c3b8e3431963e0c3ba703/chrome/browser/ui/views/frame/glass_browser_frame_view.h
[modify] https://crrev.com/a6885b5355fb39feb35c3b8e3431963e0c3ba703/ui/views/win/hwnd_message_handler.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7a7c85f7eff9c6b597782e00ffad7d20fe3dfc55

commit 7a7c85f7eff9c6b597782e00ffad7d20fe3dfc55
Author: Dirk Pranke <dpranke@chromium.org>
Date: Sat Apr 14 01:23:43 2018

Revert "Fix custom titlebar minimize button stuck hovered when clicked."

This reverts commit a6885b5355fb39feb35c3b8e3431963e0c3ba703.

Reason for revert: Speculatively reverting to see if it fixes the failure for AutomationApiTest.CloseTab is failing in site_per_process_browser_tests on Linux Tests (dbg)(1); see  crbug.com/833011  and https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Linux%20Tests%20%28dbg%29%281%29/71426

Original change's description:
> Fix custom titlebar minimize button stuck hovered when clicked.
> 
> Normally when a button is clicked we assume the mouse is still hovering
> over it, so we go back to the hovered state and wait for the mouse exit
> event. However, when the minimize button minimizes the window Windows
> gives us the mouse exit event before the mouse up event, so the button
> will get stuck in the hovered state.
> 
> This patch fixes this by resetting the button state when it receives
> a window control action, the same way the opaque frame currently solves
> this problem.
> 
> Bug:  828591 
> Change-Id: I6e3f27b8f92bcbf3fb8171555702b8cf5326ba21
> Reviewed-on: https://chromium-review.googlesource.com/1006373
> Reviewed-by: Scott Violet <sky@chromium.org>
> Commit-Queue: Bret Sepulveda <bsep@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#550733}

TBR=sky@chromium.org,bsep@chromium.org

Change-Id: I2809f8bbc666dd87b9a696eb87935cb3bd0f5e7c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug:  828591 
Reviewed-on: https://chromium-review.googlesource.com/1012476
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Dirk Pranke <dpranke@chromium.org>
Cr-Commit-Position: refs/heads/master@{#550847}
[modify] https://crrev.com/7a7c85f7eff9c6b597782e00ffad7d20fe3dfc55/chrome/browser/ui/views/frame/glass_browser_frame_view.cc
[modify] https://crrev.com/7a7c85f7eff9c6b597782e00ffad7d20fe3dfc55/chrome/browser/ui/views/frame/glass_browser_frame_view.h
[modify] https://crrev.com/7a7c85f7eff9c6b597782e00ffad7d20fe3dfc55/ui/views/win/hwnd_message_handler.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b9ac15055efa2c182e93c519e6ce5b2d808116e0

commit b9ac15055efa2c182e93c519e6ce5b2d808116e0
Author: Dirk Pranke <dpranke@chromium.org>
Date: Sat Apr 14 04:10:51 2018

Reland "Fix custom titlebar minimize button stuck hovered when clicked."

This reverts commit 7a7c85f7eff9c6b597782e00ffad7d20fe3dfc55.

Reason for revert: This doesn't seem to have been the problem. I'm now guessing that https://crrev.com/c/996458 was the problem, because that was in the original blamelist, and was reverted, and the test stopped failing when that was reverted, but not this CL.

Original change's description:
> Revert "Fix custom titlebar minimize button stuck hovered when clicked."
> 
> This reverts commit a6885b5355fb39feb35c3b8e3431963e0c3ba703.
> 
> Reason for revert: Speculatively reverting to see if it fixes the failure for AutomationApiTest.CloseTab is failing in site_per_process_browser_tests on Linux Tests (dbg)(1); see  crbug.com/833011  and https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Linux%20Tests%20%28dbg%29%281%29/71426
> 
> Original change's description:
> > Fix custom titlebar minimize button stuck hovered when clicked.
> > 
> > Normally when a button is clicked we assume the mouse is still hovering
> > over it, so we go back to the hovered state and wait for the mouse exit
> > event. However, when the minimize button minimizes the window Windows
> > gives us the mouse exit event before the mouse up event, so the button
> > will get stuck in the hovered state.
> > 
> > This patch fixes this by resetting the button state when it receives
> > a window control action, the same way the opaque frame currently solves
> > this problem.
> > 
> > Bug:  828591 
> > Change-Id: I6e3f27b8f92bcbf3fb8171555702b8cf5326ba21
> > Reviewed-on: https://chromium-review.googlesource.com/1006373
> > Reviewed-by: Scott Violet <sky@chromium.org>
> > Commit-Queue: Bret Sepulveda <bsep@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#550733}
> 
> TBR=sky@chromium.org,bsep@chromium.org
> 
> Change-Id: I2809f8bbc666dd87b9a696eb87935cb3bd0f5e7c
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug:  828591 
> Reviewed-on: https://chromium-review.googlesource.com/1012476
> Reviewed-by: Dirk Pranke <dpranke@chromium.org>
> Commit-Queue: Dirk Pranke <dpranke@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#550847}

TBR=sky@chromium.org,dpranke@chromium.org,bsep@chromium.org

Change-Id: I24d630ab51c665b9df680cdcdbfd0ffe5a1b4fe7
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug:  828591 
Reviewed-on: https://chromium-review.googlesource.com/1013268
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Dirk Pranke <dpranke@chromium.org>
Cr-Commit-Position: refs/heads/master@{#550878}
[modify] https://crrev.com/b9ac15055efa2c182e93c519e6ce5b2d808116e0/chrome/browser/ui/views/frame/glass_browser_frame_view.cc
[modify] https://crrev.com/b9ac15055efa2c182e93c519e6ce5b2d808116e0/chrome/browser/ui/views/frame/glass_browser_frame_view.h
[modify] https://crrev.com/b9ac15055efa2c182e93c519e6ce5b2d808116e0/ui/views/win/hwnd_message_handler.cc

#15/16: Yeah, it's not fixed yet. That was patch 1 of 2, the other got stuck in the CQ.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bae2319eb135aba1431b8dfb8f0ca00574bb0964

commit bae2319eb135aba1431b8dfb8f0ca00574bb0964
Author: Bret Sepulveda <bsep@chromium.org>
Date: Wed Apr 18 01:39:59 2018

Use the real mouse position when synthesizing mouse events.

Aura synthesizes a mouse event at certain times, including when the
window comes back from being minimized. Currently it uses the last known
mouse position, which works in most cases. However, the window doesn't
get mouse events when minimized, so the last known position isn't
updated. When the window comes back, if the user's mouse is not over the
window it can cause buttons to get stuck in the hovered state until the
user moves the mouse back into the window.

To fix this, this patch uses the real mouse position.

Bug:  828591 
Change-Id: I604d6ddf8f260fe32bd0e4a607f19f1793cf5c5e
Reviewed-on: https://chromium-review.googlesource.com/1006396
Commit-Queue: Bret Sepulveda <bsep@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/master@{#551551}
[modify] https://crrev.com/bae2319eb135aba1431b8dfb8f0ca00574bb0964/ui/aura/window_event_dispatcher.cc
[modify] https://crrev.com/bae2319eb135aba1431b8dfb8f0ca00574bb0964/ui/aura/window_event_dispatcher.h

Verified the fix on Windows-10 using Chrome version #68.0.3399.0 as per the comment #0.
Attaching screen cast for reference.
Observed that minimise button isn't in hovered state when cursor is away from it.
Hence, the fix is working as expected. 
Adding the verified labels.
Note: Able to reproduce the issue using chrome reported version #67.0.3387.0.

Thanks...!!

Deleted: 828591.mp4 1.9 MB

	828591.mp4 1.9 MB View Download

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1019264aa5c805ae0db82ad4253bb208342e0fbb

commit 1019264aa5c805ae0db82ad4253bb208342e0fbb
Author: Rune Lillesveen <futhark@chromium.org>
Date: Wed Apr 18 11:04:31 2018

Revert "Use the real mouse position when synthesizing mouse events."

This reverts commit bae2319eb135aba1431b8dfb8f0ca00574bb0964.

Reason for revert: layout test started failing on trusty Linux

The following test started failing (see https://ci.chromium.org/buildbot/chromium.webkit/WebKit%20Linux%20Trusty%20%28dbg%29/11682):

virtual/mouseevent_fractional/fast/events/touch/gesture/gesture-tap-mouse-events-between-frames.html

Original change's description:
> Use the real mouse position when synthesizing mouse events.
> 
> Aura synthesizes a mouse event at certain times, including when the
> window comes back from being minimized. Currently it uses the last known
> mouse position, which works in most cases. However, the window doesn't
> get mouse events when minimized, so the last known position isn't
> updated. When the window comes back, if the user's mouse is not over the
> window it can cause buttons to get stuck in the hovered state until the
> user moves the mouse back into the window.
> 
> To fix this, this patch uses the real mouse position.
> 
> Bug:  828591 
> Change-Id: I604d6ddf8f260fe32bd0e4a607f19f1793cf5c5e
> Reviewed-on: https://chromium-review.googlesource.com/1006396
> Commit-Queue: Bret Sepulveda <bsep@chromium.org>
> Reviewed-by: Scott Violet <sky@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#551551}

TBR=sky@chromium.org,bsep@chromium.org

Change-Id: I1d4448e688447d63d812046c31084f3d04121978
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug:  828591 
Reviewed-on: https://chromium-review.googlesource.com/1016601
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Commit-Queue: Rune Lillesveen <futhark@chromium.org>
Cr-Commit-Position: refs/heads/master@{#551628}
[modify] https://crrev.com/1019264aa5c805ae0db82ad4253bb208342e0fbb/ui/aura/window_event_dispatcher.cc
[modify] https://crrev.com/1019264aa5c805ae0db82ad4253bb208342e0fbb/ui/aura/window_event_dispatcher.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e35026faef6e203a3fb00d39ddf7df56bf6a3246

commit e35026faef6e203a3fb00d39ddf7df56bf6a3246
Author: Bret Sepulveda <bsep@chromium.org>
Date: Thu May 03 19:11:28 2018

Reland: Use the real mouse position when synthesizing mouse events.

Aura synthesizes a mouse event at certain times, including when the
window comes back from being minimized. Currently it uses the last known
mouse position, which works in most cases. However, the window doesn't
get mouse events when minimized, so the last known position isn't
updated. When the window comes back, if the user's mouse is not over the
window it can cause buttons to get stuck in the hovered state until the
user moves the mouse back into the window.

To fix this, this patch uses the real mouse position.

This patch also updates content_shell to move the mouse to 0,0 in
headless mode, to avoid any queries to the real mouse position from
interfering with blink tests. This patch also adds an implementation
for MoveCursorTo on Windows.

Bug:  828591 ,  834166 
Change-Id: I81354c77805c1928eb0cbccb900856a8c523709d
Reviewed-on: https://chromium-review.googlesource.com/1022959
Reviewed-by: Mike West <mkwst@chromium.org>
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Commit-Queue: Bret Sepulveda <bsep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#555843}
[modify] https://crrev.com/e35026faef6e203a3fb00d39ddf7df56bf6a3246/content/shell/browser/shell_views.cc
[modify] https://crrev.com/e35026faef6e203a3fb00d39ddf7df56bf6a3246/ui/aura/window_event_dispatcher.cc
[modify] https://crrev.com/e35026faef6e203a3fb00d39ddf7df56bf6a3246/ui/aura/window_event_dispatcher.h
[modify] https://crrev.com/e35026faef6e203a3fb00d39ddf7df56bf6a3246/ui/platform_window/win/win_window.cc