vadim.jacobi@ Thanks for the issue.

Tested this issue on Windows 10 on the reported version 69.0.3497.100 and the latest Canary 71.0.3559.0 and unable to reproduce the issue by following the below steps.

1. Launched Chrome and navigated to the above given URLs.
2. Placed the mouse inside the iframe and dragged outside the iframe. Could drag the map from outside of the iframe.
The same behavior is observed on Firefox.
Attached is the screen cast for reference.

Request you to check and confirm if anything is missed from our end in triaging the issue.
Also request you to retry the issue on a new chrome profile without any flags/extensions and update the thread with the observations.

Thanks.. 

Deleted: 888342.mp4 5.3 MB

	888342.mp4 5.3 MB View Download

I can repro this in 69.0.3497.92 and 69.0.3497.100 but not 70.0.3538.16.  I'm not sure what's different in comment 2 and why it wouldn't repro there.

Ken, it looks like you might have fixed this in  issue 647378  in r588115 (71.0.3539.0, and merged to M70).  Is that correct?

Can you also take a look at the other questions in the report?  I'm not able to repro a bug on https://www.ajax-zoom.com/examples/example13.php, for example.

(As for "a test tool for rolling back," we have a bisect-builds tool available here, if it helps: https://www.chromium.org/developers/bisect-builds-py)

Yes this is fixed in Chrome 70, and I was discussing this exact issue last week with the Maps team. If we had seen this bug in time I likely would have requested merge to M69.

Thanks for evaluating this issue!

I have made two videos, where the issue with the left mouse dragging / capturing cross-origin in Chrome 69 does not work.

The second video shows, that some applications work in Chrome 70 cross-origin. 

Unfortunately, our App does not work as cross-origin iframe embed anymore but works perfectly in same-origin iframe. Both, cross-origin and same-origin certainly worked in Chrome before. Cross-origin embed still works in Mozilla, which can be viewed in the video. Is there any documentation of what to do for events to work cross origin now / is this a bug or do you have a whitelist inside Chrome code? :-)

The right mouse dragging hold down is fixed in Canary 71.0.3559.0 for same-origin!!!

Deleted: app_not_working_cross-origin.mp4 6.0 MB

	app_not_working_cross-origin.mp4 6.0 MB View Download

Here the second video because of the size in next comment.

Deleted: chrome69_not_working.mp4 5.8 MB

	chrome69_not_working.mp4 5.8 MB View Download

Comments 6-7: Thanks for the extra context!  I can confirm that the dragging still does not work on M70 or M71 when you embed the ajax-zoom example within the Google Maps developer page.  More specific repro steps:

1) Visit https://google-developers.appspot.com/maps/documentation/embed/wizard/
2) On M70+, confirm that dragging the map continues to work as the mouse cursor leaves the map boundary.
3) Open DevTools, inspect the iframe (within the first div element), and change the src attribute to:
https://www.ajax-zoom.com/examples/example33_vario.php?3dDir=/pic/zoom3d/Uvex_Occhiali&fullScreenApi=0&spinReverse=0&mouseScrollEnable=1&spinNoInit=1
4) Try to drag the 3D model of the goggles to rotate them.  As the mouse cursor leaves the iframe, the dragging no longer works.

I can repro this on Windows on 70.0.3538.16 and 71.0.3559.0, so it's not fixed by r588115.  Ken, can you take a look at what's going on this particular case?

(For context, the cross-origin cases are using out-of-process iframes for security reasons, as part of Site Isolation: https://www.chromium.org/Home/chromium-security/site-isolation)

It looks like that is a different mouse capture vector that hasn't been covered yet. I'm working on a fix.

@Ken: 
1. Please note that it does work in same-origin context: https://www.ajax-zoom.com/examples/example13.php 
2. It used to work for Chrome in cross-origin context as it is (last good version unknown). Works cross-origin in Moz.
3. In Chrome, mouse events are used. Using pointer events and setPointerCapture instead of mouse events does not solve cross-origin issue in Chrome 70 and 71 (tested yesterday).
4. Mouse move and up event handlers are bind to document on mouse down if that makes any difference.
5. Mouse move / up is not called at all outside of the bounds.

Yes, it only happens on cross-origin frames because the different frames are rendered in different processes and the events have to be locked to the correct process. Previously we had it so that all mouse input following a MouseDown would be captured by a single process, but that isn't strictly correct and caused bugs on some sites. That was rolled back and we have had to try to separately implement cross-process mouse capture for all the instances in which Blink can capture mouse events to a target, which clearly isn't entirely correct yet.

Here are several broken scenarios in Office Online apps, e.g. Excel Online that resides in an iframe.
1) Press the left mouse button (and keep it pressed)
   1.1) Selection: Having pressed the button within a column/row header.
   1.2) Selection: Having pressed the button within a cell.
   1.3) Fill: Having pressed the button on a corner of the current selection.
   1.4) Drag: Having pressed the button on the border of the current selection.
2) Move the mouse off the browser window.
3) Release the mouse button.
4) The result - The mouseup/pointerup events are not sent to the iframe.
   4.1) Selection, Fill: the selection keeps growing (and the document keeps scrolling).
   4.2) Drag: the dragged range is `awaiting` for mouse events.

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

commit 3561c3c6f73f447b803ef49b8c2f86c181e7edb7
Author: Ken Buchanan <kenrb@chromium.org>
Date: Fri Oct 12 23:23:50 2018

Make subframe widgets implicitly capture mouse events on MouseDown

Frame-level capture of mouse events implicitly happens when a MouseDown
is targeted to an element in a subframe. Currently this does not work
across frames in different processes because the browser process does
not receive a notification about capture being active.

This patch adds that notification in order to initiate widget-level
capture in that case.

Bug:  888342 ,  647378 
Change-Id: I26f55b2690e9ecfbd0243a9a610541abdff3b575
Reviewed-on: https://chromium-review.googlesource.com/c/1271588
Commit-Queue: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/heads/master@{#599408}
[modify] https://crrev.com/3561c3c6f73f447b803ef49b8c2f86c181e7edb7/content/browser/site_per_process_hit_test_browsertest.cc
[modify] https://crrev.com/3561c3c6f73f447b803ef49b8c2f86c181e7edb7/third_party/WebKit/LayoutTests/FlagExpectations/site-per-process
[modify] https://crrev.com/3561c3c6f73f447b803ef49b8c2f86c181e7edb7/third_party/blink/renderer/core/input/event_handler.cc
[modify] https://crrev.com/3561c3c6f73f447b803ef49b8c2f86c181e7edb7/third_party/blink/renderer/core/input/event_handler.h

The fix in comment 13 has rolled to Canary and the repro steps from comment 8 no longer work for me. I'd like to merge this to 71 after it has had a few days to bake.

If anyone is having a similar problem around pointer capture in the PointerEvents API, that still needs to be addressed separately.

The fix in Canary is working well for my scenarios.
!!!THANKS!!!

I can confirm, that both, left and right mouse events capturing outside of the cross-domain iframe work perfectly now in Canary for this issue / scenario. Fixed. Thanks a lot!

Your change meets the bar and is auto-approved for M71. Please go ahead and merge the CL to branch 3578 manually. Please contact milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), kbleicher@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

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

commit fd61bc6783b1a3a18db49f860cbe1b92fa25475b
Author: Ken Buchanan <kenrb@chromium.org>
Date: Fri Oct 19 19:35:32 2018

Make subframe widgets implicitly capture mouse events on MouseDown

Frame-level capture of mouse events implicitly happens when a MouseDown
is targeted to an element in a subframe. Currently this does not work
across frames in different processes because the browser process does
not receive a notification about capture being active.

This patch adds that notification in order to initiate widget-level
capture in that case.

Bug:  888342 ,  647378 
Change-Id: I26f55b2690e9ecfbd0243a9a610541abdff3b575
Reviewed-on: https://chromium-review.googlesource.com/c/1271588
Commit-Queue: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#599408}(cherry picked from commit 3561c3c6f73f447b803ef49b8c2f86c181e7edb7)
Reviewed-on: https://chromium-review.googlesource.com/c/1292272
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Cr-Commit-Position: refs/branch-heads/3578@{#164}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}
[modify] https://crrev.com/fd61bc6783b1a3a18db49f860cbe1b92fa25475b/content/browser/site_per_process_hit_test_browsertest.cc
[modify] https://crrev.com/fd61bc6783b1a3a18db49f860cbe1b92fa25475b/third_party/WebKit/LayoutTests/FlagExpectations/site-per-process
[modify] https://crrev.com/fd61bc6783b1a3a18db49f860cbe1b92fa25475b/third_party/blink/renderer/core/input/event_handler.cc
[modify] https://crrev.com/fd61bc6783b1a3a18db49f860cbe1b92fa25475b/third_party/blink/renderer/core/input/event_handler.h

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

Commit: fd61bc6783b1a3a18db49f860cbe1b92fa25475b
Author: kenrb@chromium.org
Commiter: kenrb@chromium.org
Date: 2018-10-19 19:35:32 +0000 UTC

Make subframe widgets implicitly capture mouse events on MouseDown

Frame-level capture of mouse events implicitly happens when a MouseDown
is targeted to an element in a subframe. Currently this does not work
across frames in different processes because the browser process does
not receive a notification about capture being active.

This patch adds that notification in order to initiate widget-level
capture in that case.

Bug:  888342 ,  647378 
Change-Id: I26f55b2690e9ecfbd0243a9a610541abdff3b575
Reviewed-on: https://chromium-review.googlesource.com/c/1271588
Commit-Queue: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#599408}(cherry picked from commit 3561c3c6f73f447b803ef49b8c2f86c181e7edb7)
Reviewed-on: https://chromium-review.googlesource.com/c/1292272
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Cr-Commit-Position: refs/branch-heads/3578@{#164}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}