coolcmd@ Thanks for the issue.

Able to reproduce the issue on Windows 7 on Chrome Beta 68.0.3440.33 by following the steps mentioned in the original comment.
Issue is not observed on Windows 10, Mac OS 10.13.5 and Ubuntu 14.04 on the reported version 68.0.3440.33 and the latest Canary 69.0.3469.3.

Note : Issue is not observed on the Beta equivalent Dev build 68.0.3440.33 on Windows 7. Issue is only observed on Beta build 68.0.3440.33.

As the issue is inconsistent, unable to provide the Bisect information and the Changelog URL.
Hence marking this issue as Untriaged for further updates from Dev.

Thanks..

This issue is also observed on Canary 68.0.3418.2 on Windows 10.

Site Isolation get first crack at this. Send it to HitTesting if that's where the problem lies.

Ken, can you take a look at the repro, given the pointer-events and position interaction?  Also adding Daniel for drag n drop.

If the motivating example is an extension, then I would imagine the bug happens even when disabling Site Isolation with chrome://flags/#site-isolation-trial-opt-out, correct?  Site Isolation would indeed make the bug apply to web sites as well.

Note: Comment 2 seems to indicate that there's probably some other factor involved which is inconsistent across builds/platforms.  I'm guessing another field trial needs to be active, such as Viz Quad Hit Testing.  If someone can confirm that, we should add the Viz component back.

We know there are bugs with targeting during drag and drop, because it doesn't use asynchronous hit testing. That's not really compatible with the nested event loop during a drag. So things like invisible targets and pointer-events:none elements will cause problems here.

This particular example only regresses with Viz hit testing -- disabling the #enable-viz-hit-test-draw-quad experiment resolves the problem.

I believe this is because the current hit testing system includes a hack for iframes with pointer-events:none, disqualifying them from browser hit tests during the synchronous case. The new Viz region-based system doesn't have that hack.

In both the old and new systems we would still see digressions in behavior if you did something like have a pointer-events:none div on top of an OOPIF. I thought we had a bug open talking about this but I can't see one atm.

Non-empty Owner field => Status=Assigned.