marking as RBB, please change if required.

Given the issue already present on current beta i.e., 67.0.3396.18, I would not block 67.0.3396.30 beta release on this.

tangltom@ can you please get the fix in canary by end of this week so that we can consider the fix into beta refresh next Wednesday.

+tapted CL reviewer as 	tangltom@ is OOO  (Suspect: https://chromium.googlesource.com/chromium/src/+/bda1898036dc3ddac9e4d5f9df2f76f68b072d51)

I think the profile switcher is a red herring. The bug seems to lie in the caption buttons.

Here is another repro:

1) Have two Chrome windows, side-by-side.
2) On the focused window touch-drag the maximize button (e.g., upwards from the centre of the maximize button).
3) Tap the content area of the other window.

Expected: the other Chrome window should get focused.

Actual: It doesn't. Browser seems unresponsive to touch until the omnibox is tapped - that immediately causes the copy/paste touch context menu to appear (which is a bug - it should need a tap-hold). Things still seem unresponsive until that popup is dismissed (e.g. by tapping the titlebar). Then browser is responsive again. I suspect some SetCapture issue..

This doesn't happen for me in m66. But it does in m68. Can we try bisecting on the repro above? I don't think the HoverButton changes in r544666 would have any influence on the caption buttons.

Is that a Windows-only issue?

Seems like it is specific to Windows per comment #0 "Issue is not seen on Linux (14.04 LTS) and Mac (10.12.6, 10.13.1, 10.13.5) OS.".

Yeah, I think Windows-only. I couldn't repro on ChromeOS 68.0.3416.0. Mac has no touch events.

I bisected to https://chromium.googlesource.com/chromium/src/+log/8e8d78880849513e050f3dc5e77a360701e4dad1..c27ca05e015a4275604c48611ef752d1ff41930d

suspect:
https://chromium-review.googlesource.com/972607 "Add Windows 10 Custom Titlebar feature flag and enable it by default."

(taking off Needs-Bisect, but a per-rev bisect might still be satisfying to have - the one above isn't per-rev since our windows touchscreen is off corp)

With respect to comment #9, re-bisected the above issue and providing the bisect using per-bisect revision:

You are probably looking for a change made after 544787 (known good), but no later than 544788 (first known bad).

CHANGE-LOG URL:

The script might not always return single CL as suspect as some perf builds might get missing due to failure.

https://chromium.googlesource.com/chromium/src/+log/cd54fed5e109370d5dd84d59e01819c1b786aefd..979c3c4d8355e456339c648db65c8201991b43af

Suspect: https://chromium.googlesource.com/chromium/src/+/979c3c4d8355e456339c648db65c8201991b43af

@bsep: Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thanks folks for taking this over! I'm currently in Vietnam in a very separated area, so I don't have a lot of access to Wifi. I just saw the emails.

This is probably unrelated, but I add it here just in case. There was an issue concerning touch/tap that occurred a few weeks ago. The tap wasn't visible in the avatar menu. This bug was fixed by pbos@ here:
https://bugs.chromium.org/p/chromium/issues/detail?id=832056

Also note, I can't debug touch/tap issues because our team doesn't own a touch screen device (yet).
Though let me know if you need anything that you think I can help with!

Interesting... I'll take a look. There have been a couple touch bugs with the new caption buttons, but this one is very concerning.

Thank you bsep@. Pls land fix to trunk ASAP and request a merge to M67. If merge happens latest by 11:30 AM Tuesday (05/08), then we can take it in for next week beta. 

Update: I found the root issue but when I wrote a CL I uncovered multiple other issues. So I'm still working on it... there are clearly some longstanding flaws with touch so I'm changing this to RBS, but I'll land and merge as soon as possible.

Thank you  bsep@. Pls request a merge to M67 once change is landed, baked/verified in canary and ready for merge. 

*** Bulk Edit ***
M67 Stable promotion is coming VERY soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. 

If fix is already merged to M67 and nothing else is pending, pls mark the bug as fixed. Thank you.

I have a CL ready, but I discussed this with the team and it's an extremely high-risk merge: no test coverage, fragile code, affects all touch input. We're willing to live with this bug for one release instead. Thus, un-marking as RBS. I will land the fix for 68.

By the way, you can escape the broken state by touching the desktop outside the browser window, by touching the minimize button and then bringing the window back, or by using the mouse to click anywhere.

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

commit f99e202ce1f30e12b84d2138fc2d6cd1b32fee79
Author: Bret Sepulveda <bsep@chromium.org>
Date: Tue May 15 01:03:04 2018

Fix IsMouseEventFromTouch not handling non-client mouse events.

Split off from crrev.com/c/1048877. IsMouseEventFromTouch would always
return false for non-client mouse events even if they were from touch.
HWNDMessageHandler lets these fall through anyway so this change alone
does not fix any bugs (as far as I know).

Bug:  838870 ,  832291 
Change-Id: I2fc58816b7586a3347fade9e8171362137a2cbf5
Reviewed-on: https://chromium-review.googlesource.com/1058548
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Bret Sepulveda <bsep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#558565}
[modify] https://crrev.com/f99e202ce1f30e12b84d2138fc2d6cd1b32fee79/ui/events/win/events_win.cc

Rechecked the above issue on latest Canary build #68.0.3432.0 for Windows 10 OS (Touch Device) and the issue is still reproducible.

Please refer the attached screen-cast.

Deleted: Actual Video_#68.0.3432.0.mp4 195 KB

	Actual Video_#68.0.3432.0.mp4 195 KB View Download

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

commit fdafd691ac38754d9b2e2ef1990d0b478985ac0b
Author: Bret Sepulveda <bsep@chromium.org>
Date: Mon May 21 21:51:49 2018

Fix strange touch behavior on Windows titlebar.

This patch fixes three bugs:
* Dragging the window via finger touch on the titlebar only works about
50% of the time.
* Touching the custom titlebar caption buttons would "leak" to the
window underneath, if the top window was closed or minimized.
* Touching and dragging the custom titlebar caption buttons would
cause further touch input on other widgets (like popup bubbles) to
not work.

This patch fixes them all at once by revising how we handle mouse events
synthesized from touch:
* We were letting all mouse events synthesized from touch fall through
as regular mouse events, unless they were targeted at HTCLIENT. They
would cause problems like setting mouse capture incorrectly (causing bug
#3) and cause double inputs ( bug #2 ). This patch instead marks these
events as handled and ignores them, unless otherwise noted below.
* We now DefWindowProc events targeted at HTCAPTION and HTSYSMENU
instead of simply ignoring them, which fixes bug #1. Our special drag
handling in HandleMouseInputForCaption works poorly for touch.
* We also DefWindowProc events targeted at the caption buttons when
custom titlebar is off, which is required for them to work.
* When we do the hittest for the above targeting, we no longer convert
LPARAM to window coordinates before sending WM_NCHITTEST, because the
point should remain in screen coordinates. This was causing all three
bugs to reproduce inconsistently, since we would sometimes get HTCLIENT
or HTNOWHERE for events clearly targeting non-client area.

This patch doesn't specifically address the broken pen touch case, but
as a side effect it makes dragging the window with the pen work slightly
more often.

Bug:  838870 ,  832291 ,  843486 
Change-Id: Ie7d339f7b1b75acb14377d8411234d8faa16755f
Reviewed-on: https://chromium-review.googlesource.com/1048877
Commit-Queue: Bret Sepulveda <bsep@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/master@{#560353}
[modify] https://crrev.com/fdafd691ac38754d9b2e2ef1990d0b478985ac0b/chrome/browser/ui/views/frame/browser_view_layout.cc
[modify] https://crrev.com/fdafd691ac38754d9b2e2ef1990d0b478985ac0b/ui/views/win/hwnd_message_handler.cc

Rechecked the above issue with same steps on latest Canary build #68.0.3437.2 for Windows 10 OS (Touch device) and the issue is fixed.

Please refer the attached screen-cast.

Deleted: Fixed Video.mp4 913 KB

	Fixed Video.mp4 913 KB View Download