Thanks for the report!  Confirmed that this repros on Linux 67.0.3396.87 with wheel scrolling, as well as Mac Canary 69.0.3466.0 with two-finger touchpad scrolling.  This appears related to site isolation, as it doesn't repro after turning it off on 69.0.3466.0.  Can you confirm whether setting chrome://flags#site-isolation-trial-opt-out to "Opt out" fixes this?

We've seen similar bugs reported in issues  852932 ,  854558 , and  851802 ; not sure yet if this one is a dupe or a new issue.

Setting chrome://flags#site-isolation-trial-opt-out to "Opt out" and relaunching Chrome did not fix the issue for me with macOS Chrome 67.0.3396.87 (I tried both my simple repro and our product where we discovered the issue)

Interesting! This seems to be fixed by Viz Quad Hit Testing instead, which can be turned on by setting chrome://flags/#enable-viz-hit-test-draw-quad.

(I can confirm that I see it even without Site Isolation.)

In this case it reproduces with Site Isolation turned off because that is a MimeHandlerView, which is still out of process. This might be something specific to routing with BrowserPlugin.

mcnee@ just reminded me this is a known issue:  bug 802378 . It was an open question whether that is worth fixing directly, since it becomes mostly fixed when Viz hit testing fully ships, and entirely fixed when PDFs are moved to OOPIFs.

This isn't a regression. I am surprised that Viz quad hit testing fixes it, because I didn't think it was aware of pointer-events:none yet when generating hit test regions (i.e. I thought that was still work in progress).

Thanks everyone for helping triage this.  Adjusting labels based on latest comments.  Turns out Viz Quad Hit Testing is enabled by default on dev builds and the waterfall via fieldtrial_testing_config.json, which is why this didn't repro for me on Linux ToT even though I didn't explicitly enable the feature.

Should we mark this as blocked by issue 659750?

re c#7, do we know at which stage current hit-testing is failing? If it's because we are not doing async targeting for guest-views [1], it should mean that we have already found the pdf as target, which is the correct target in this case since the div above it has pointer-events:none? I'm also surprised VizHitTestDrawQuad would make a difference here because it should stop at [1] as well.

re c#8, yea VizHitTestDrawQuad is enabled for 50% on dev.

[1] https://cs.chromium.org/chromium/src/content/browser/renderer_host/render_widget_targeter.cc?sq=package:chromium&g=0&l=157

Ria, what's the status of VizHitTestDrawQuad now?

VizHitTestDrawQuad is on 100% stable on non-cros platforms, it's 50% beta and 1% stable on cros.