Able to reproduce the issue on reported version 62.0.3202.94 and latest Canary 64.0.3274.0 using Mac 10.12.6, Ubuntu 14.04 and Windows 10.

Bisect info:
----------------------
Good Build: 55.0.2875.0
Bad Build: 55.0.2876.0

You are probably looking for a change made after 421810 (known good), but no later than 421811 (first known bad).
CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+log/bd027238e7f3d3c8096c1a62e9063d8cbf5d8a80..902a3d6303dfbfd49a24173777afcb4b70234a17

Suspecting the same changelog
Review-Url: https://codereview.chromium.org/2375493005

@mustaq, : Please confirm the issue and help in re-assigning if it is not related
to your change.

Thanks!

I don't think this is P1: we haven't heard about the problem in the last 1+ years after we launched PointerEvents through the suspect CL (perhaps because it's very hard to repro).

I'm quite confident that I could not reproduce this problem with the previous stable build though and that it was therefore introduced recently. This breaks our product quite badly.

I just tried on 60.0.3112.113 and the problem does not occur there.

Thanks jkieboom@ for confirming it's a recent breakage.  I can't recall any recent changes that could have caused this.  Let's bump up the priority and ask for a new bisect.

Able to reproduce the issue on 60.0.3112.113 using Mac 10.12.6, Ubuntu 14.04 and Win 10 as per below steps:
1. Open test.html in chrome
2. Right-click on the element + quickly move the pointer around 100px or away from where it is clicked
3. Observed the green square box moves over and out of red square box when using chrome but the green square box does not move when using Firefox or safari

We confirm that the issue is reproducible on 60.0.3112.113, please find the attached screen-cast for your perusal

@mustaq, request your inputs on the same

Deleted: 787365.mp4 682 KB

	787365.mp4 682 KB View Download

The correct behavior is for the green box to continue moving. In latest chrome stable, a lostpointercapture event is received while the capture is supposed to be held (from right clicking) which stops the green box. There are some console messages in the test page that will show when this happens. 

Sorry if this repro test is a bit confusing, I can write a better one if that helps? I actually didn't test this repro test.html on firefox/safari, so maybe I did something non-compatible (but unrelated to the bug).

Neither Safari nor Firefox supports PointerEvents, so the bug doesn't apply to them.

Observations:
1) In Build# 55.0.2875.0, when we "Right-click on the element + quickly move the pointer around 100px" with in the red box (or) outside of the red box and release the right button, then the green box will get stop moving and 
2) On the reported Build# 62.0.3202.94 and latest canary Build# 65.0.3298.0, when we "Right-click on the element + quickly move the pointer around 100px" with in the red box and release the button then the green box will get stop moving and if we release the right button out side of the red box then the green box continues moving

@Reporter:
Please find the attached screen cast for your reference and provide your feedback on it,
If possible can you please provide the screencast of the excepted behaviour of this issue which helps us in further triaging it.

Thanks!

Deleted: 787365.mp4 1.2 MB

	787365.mp4 1.2 MB View Download

I can repro consistently now, have to move the mouse really fast.

Looks like a strange thing: the |buttons| field in a mosuemove event is not set, so PointerEventManager releases the capture.  Investigating.

Here is the root cause: our fix to update hover-state on layout change fires a fake mousemove event on timer, which doesn't have the button-press info.
https://chromium.googlesource.com/chromium/src/+/122b716f3278b62d6a2d837383bdaea6527f0d4c

To make my last comment more precise, there is another hack that affects the behavior of the fake mouse event here: when right-click drag is done quickly after mousedown, MouseEventManager::HandleMouseDraggedEvent gets called before the fake mouse move event timer fires.  The HandleMouseDraggedEvent method has a hack to force the release of mouse events, see:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/input/MouseEventManager.cpp?rcl=1c610bb9ca28d976c23c0f7c4712ff0bdbb33503&l=773

As a result, the fake mouse events see no buttons are down, which releases the pointer capture.

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

commit 8f44a94319302b7ce0410e0677842fd3908c641e
Author: Mustaq Ahmed <mustaq@google.com>
Date: Wed Dec 20 18:34:04 2017

Fix pointer capture release caused by fake mouse moves.

Fake mousemoves shouldn't release pointer capture.

An ideal fix would be to make |button| for all fake events
(mousemove and boundary events) reflect true mouse state.
Unfortunately MouseEventManager::HandleMouseDraggedEvent
has an old hack that makes the ideal fix useless.

This CL also updates a few names & comments to reflect the current
state of the code.

Bug:  787365 
Change-Id: Ie380c959dd0c44a14cc2517574372e4118654736
Reviewed-on: https://chromium-review.googlesource.com/832349
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Navid Zolghadr <nzolghadr@chromium.org>
Commit-Queue: Mustaq Ahmed <mustaq@chromium.org>
Cr-Commit-Position: refs/heads/master@{#525380}
[modify] https://crrev.com/8f44a94319302b7ce0410e0677842fd3908c641e/third_party/WebKit/Source/core/input/EventHandler.cpp
[modify] https://crrev.com/8f44a94319302b7ce0410e0677842fd3908c641e/third_party/WebKit/Source/core/input/EventHandler.h
[modify] https://crrev.com/8f44a94319302b7ce0410e0677842fd3908c641e/third_party/WebKit/Source/core/input/MouseEventManager.cpp
[modify] https://crrev.com/8f44a94319302b7ce0410e0677842fd3908c641e/third_party/WebKit/Source/core/input/MouseEventManager.h
[modify] https://crrev.com/8f44a94319302b7ce0410e0677842fd3908c641e/third_party/WebKit/Source/core/input/PointerEventManager.cpp