Unable to narrow down the range using per-revision script as getting traceback error between this range, hence providing bisect using old script.

Narrow bisect URL :

https://chromium.googlesource.com/chromium/src/+log/5a0c41f5f60be32ed2ca723060bc088af531c89b..c12ce092c44a325d78baaa9679ecfe7370fd1fe3?pretty=fuller&n=10000

Suspect: r558565

@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.

Note: Issue is not seen on Windows(7,8,8.1,10) ,Mac(10.12.6 , 10.13.1 , 10.13.5) OS and Linux(14.04 LTS) OS.

marking as RBD, please change if required.

Issue is Touch specific, moving as RBB. But please have a fix/revert ASAP.

Oh, strange. It looks like a problem arising from splitting a CL into two parts; only the first part is landed so far. I'll try to get the second part landed as soon as possible.

Friendly ping to get an update on this issue as it is marked as RBB.
Thanks..!

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

Update : 
Retested the above issue using latest Canary build #68.0.3437.2 on Windows-10 Touch OS and the issue is fixed. Manage people window gets close after tap/touch on close button.
 
Kindly review an attached screen-cast.

Thank you..!

Deleted: Canary_behaviour.mp4 525 KB

	Canary_behaviour.mp4 525 KB View Download