It seems that the scrolling issue is only observed when the Viz OOP-D flag is enabled. Is this flag on for any of Beta/Stable? (I'm guessing no ...)

Assigning to jonross@ for triage.

(Note: the scrollbar issue is unrelated, and should be in a separate bug.)

A little more info to help with this bug: the root cause of the TouchEmulation scrolling issue seems to be that the MouseDown event (that triggers the emulated TouchStart) has it's position transformed correctly, but the subsequent MouseMove events (which are used to create the emulated TouchMove events) seem to be getting an *extremely* different point transformation here:

https://cs.chromium.org/chromium/src/content/browser/renderer_host/render_widget_host_input_event_router.cc?rcl=dd87845938ed7631807b26bfd150fce08740287b&l=410

in RenderWidgetHostInputEventRouter::FindMouseEventTarget

Note that this line is only hit when the mouse_capture_target_.target is non-null, as is the case during touch emulation.

I'm guessing with OOP-D enabled, the transformation here somehow differs from what is happening elsewhere for the initial (MouseDown) event.

danakj@, have you updated your repo since you filed this? It looks like it might have been fixed (I pulled this morning, and now can't repro either way). I'd like to do a bisect, but need a good starting point.

I synced to ToT this morning (47ddfcfb6e439e6a1f0a8487cd4e870ae573ab12) and cannot reproduce this.

A suspected fix was not the case (https://chromium-review.googlesource.com/c/1359324) so wjmaclean@ is running a quick bisect. As it would be good to find out how this was failing.

+sunxd@ and riagiang@ whom worked on VizHitTesting.

When OOP-D is enabled viz HitTestProviderDrawQuad is used to generate hit test data, so the suspected fix shouldn't work as it was fixing layer-tree generated data.

However the behaviour looks exactly the same to the bug which the suspected patch attempts to fix. In that bug, the hit test region has an offset because the region is clipped, but we mistakenly treat the *clipping* offset as a *transform* offset and translate the point coord with the *clipping* offset.

We can't reproduce this, and do not have a bisect range to look at. If anyone sees this again please re-open.