Thanks for the report!  This sounds like it might possibly be a dupe of issue 793784 (which wasn't specific to multiple monitors), which is fixed in Chrome 65.  Ken or Sadrul, can you confirm or check whether this still repros in 65/66?

( Issue 803442  might also be related, if the monitor is at a different DPI.)

This is reported against Chrome/66.0.3334.0, which includes the fixes that went in the M65-branch. So I suspect this is still not fixed in ToT, and is very likely to indeed be affected by  issue 803442 .

Thanks all -- it's definitely reproducible in v64 and believe it was reproducible in Chrome Canary 66.0.3334.0. I'm currently not in a spot to retry, but will attempt it again soon (less than 12 hours) and provide a video of the results in v66 if it's helpful.

As per comment #4, the reporter has to check the issue on the latest Canary and provide observations.
Hence adding Needs-Feedback label.

Thanks.

In Stable 64.0.3282.119, the issue is reproducible as described in the original description. None of the video is clickable.

In Canary 66.0.3334.0, I was able to reproduce the issue, but only part of the iframe/video is not clickable. I've attached a video which shows the issue. The first 15 seconds are on the external monitor where the issue is observed, and the last 15 seconds are on the laptop screen where it functions as expected (both with the flag on).

https://www.youtube.com/watch?v=mCpNRMXlNXU&feature=youtu.be

Browser window:
Sized at 2354 x 1442

Laptop screen:
Built-in display, 15.4-in (2880 x 1800)

External screen:
HP Z30i, 30-in (2560 x 1600)

Device:
MacBook Pro (Retina, 15-in, Mid 2015)
2.5 GHz Intel Core i7
16 GB 1600 MHz DDR3
Intel Iris Pro 1536 MB

Comment 7: Interesting!  So the fixes for issue 793784 (as tracked in  issue 796651 ) may have helped, since they improve hit testing for input events over an out-of-process iframe.  It may just be coincidence, but in the video it looks like the hand cursor turns into an arrow cursor at about 0:03 when it passes horizontally over the point that the video had buffered in the video timeline-- if that's true in general, maybe there's an overlay affecting the hit testing result.

Still, I tend to agree with sadrul@ that overall this sounds similar to the bug that oshima@ is fixing in  issue 803442 .  oshima@, can you check if your CL (https://chromium-review.googlesource.com/c/chromium/src/+/882301) fixes this issues as well, or if it looks like something else is involved?

If it's not the same bug, maybe sadrul@ can take a look to see if it's a remaining hit testing issue after all the work in  issue 796651 ?

I still strongly suspect the same underlying cause as  issue 803442 : the web-page (not totally sure if the main-page or the opoif-page) does not update the internal scale-factor, which is used for hit-testing. So when the scale-factor changes (when moving from internal monitor to external monitor), hit-testing breaks (and fixes itself when moved back into the first monitor).

The  bug 803442  is specific to use-zoom-for-dsf mode, so if this happens on Mac, then it'd be different. I could still be related though. Looking now.

One thing I noticed that is different on mac vs. aura: on mac, DSF change triggers setting the device-scale-factor on LocalFrame [1], and on aura, it triggers setting the zoom-factor instead [2]. In the latter case, document->UpdateStyleAndLayoutIgnorePendingStylesheets() gets called, whereas it doesn't seem to be called in [1]. Not really sure if it affects updating hit-test related data though.

[1] https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/frame/LocalFrame.cpp?type=cs&sq=package:chromium&l=672
[2] https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/frame/LocalFrame.cpp?type=cs&sq=package:chromium&l=619

so my CL indeed fixed the issue. There was an issue in non zoom-for-dsf mode as well, and it did exhibit the issue differently.