Thanks for filing.

The date picker problem looks old, but the coordinate transformation issue appears to be a regression, because I can't repro that part on stable.

This is reproducible in DevTools emulator, so I'll try debugging on desk-top to start.

Daniel, it appears that enabling "Viz Hit-test Draw-quad version" resolves the coordinate issue. Do you want to confirm?

Yep, that fixes it for me.

+sunxd@, I think this might be caused by VizHitTestSurfaceLayer (hence we have to explicitly enabling VizHitTestDrawQuad). I can't test that on Android Canary cuz VizHitTestSurfaceLayer is not in chrome://flags, could you see if it's caused by VizHitTestSurfaceLayer? Thanks!

Thanks for filing the bug! It really helped us identifying the current unknown wrong cases of v2 viz hit testing.

Running with a devtools emulator:

1) Disable viz hit testing: clicking does not get response correctly
2) Draw quad viz hit testing: it behaves correctly
3) Surface layer viz hit testing: clicking does not get response correctly

There is definitely something wrong with v2. I'll take this bug and resolve the surface-layer case, and will see if the surface hit test case still have the bug.

It seems in non-viz and v2 hit testing, the bug happened during MouseUp, MouseDown does correctly find the target with the correct coord, but in MouseUp, RWHIER computes a wrong coord:

Index: 0
Children: 3
Flags: Mine, Mouse, Touch
Frame Sink Id: FrameSinkId(0, 1)
Rect: 0,0 2786x2078
Transform:
[ +1.0000 +0.0000 +0.0000 +0.0000  
  +0.0000 +1.0000 +0.0000 +0.0000  
  +0.0000 +0.0000 +1.0000 +0.0000  
  +0.0000 +0.0000 +0.0000 +1.0000 ]

		Index: 1
		Children: 1
		Flags: Mine, ChildSurface, Mouse, Touch
		Frame Sink Id: FrameSinkId(9, 2)
		Rect: 0,0 822x1646
		Transform:
		[ +1.0000 +0.0000 +0.0000 -982.0000  
		  +0.0000 +1.0000 +0.0000 -296.0000  
		  +0.0000 +0.0000 +1.0000 -0.0000  
		  +0.0000 +0.0000 +0.0000 +1.0000 ]
		
				Index: 2
				Children: 0
				Flags: Mine, ChildSurface, Ask, Mouse, Touch
				Frame Sink Id: FrameSinkId(10, 5)
				Rect: 0,726 722x1646
				Transform:
				[ +1.0000 +0.0000 +0.0000 -50.0000  
				  +0.0000 +1.0000 +0.0000 +726.0000  
				  +0.0000 +0.0000 +1.0000 -0.0000  
				  +0.0000 +0.0000 +0.0000 +1.0000 ]
				
		Index: 3
		Children: 0
		Flags: Mine, ChildSurface, Mouse, Touch
		Frame Sink Id: FrameSinkId(12, 6)
		Rect: 0,0 2770x1908
		Transform:
		[ +1.0000 +0.0000 +0.0000 -8.0000  
		  +0.0000 +1.0000 +0.0000 -162.0000  
		  +0.0000 +0.0000 +1.0000 -0.0000  
		  +0.0000 +0.0000 +0.0000 +1.0000 ]

Route MouseDown 853.5, 777.5 to FrameSinkId(10, 5): 312.500000,982.500000
Route MouseUp 853.5, 777.5 to FrameSinkId(10, 5): 312.500000,619.500000

--------------------------------------------------------------------------
Where "619.5" above should be "982.5".

Hi Ria, are you aware of anything that could cause a difference in computing latched event coord between v1 and v2?

In the above data, device scale factor is 2.

It seems like region[2]'s position.y is not accounted when computing the coord the second time:
619.5 + 726 / 2 = 982.5

If I delete these two lines (https://cs.chromium.org/chromium/src/components/viz/host/hit_test/hit_test_query.cc?rcl=9887251b9a16ab4651666766fb5717fc9ba8497e&l=261) the hit testing work correctly.

I also notice that v1 generates a slightly different region[2]:
Index: 0
Children: 3
Flags: Mine, Mouse, Touch
Frame Sink Id: FrameSinkId(0, 1)
Rect: 0,0 2786x2078
Transform:
[ +1.0000 +0.0000 +0.0000 +0.0000  
  +0.0000 +1.0000 +0.0000 +0.0000  
  +0.0000 +0.0000 +1.0000 +0.0000  
  +0.0000 +0.0000 +0.0000 +1.0000 ]

		Index: 1
		Children: 1
		Flags: Mine, ChildSurface, Mouse, Touch
		Frame Sink Id: FrameSinkId(7, 2)
		Rect: 0,0 822x1646
		Transform:
		[ +1.0000 +0.0000 +0.0000 -982.0000  
		  +0.0000 +1.0000 +0.0000 -296.0000  
		  +0.0000 +0.0000 +1.0000 -0.0000  
		  +0.0000 +0.0000 +0.0000 +1.0000 ]
		
				Index: 2
				Children: 0
				Flags: Mine, ChildSurface, Ask, Mouse, Touch
				Frame Sink Id: FrameSinkId(8, 5)
				Rect: 0,0 722x11612
				Transform:
				[ +1.0000 +0.0000 +0.0000 -50.0000  
				  +0.0000 +1.0000 +0.0000 +1044.0000  
				  +0.0000 +0.0000 +1.0000 -0.0000  
				  +0.0000 +0.0000 +0.0000 +1.0000 ]
				
		Index: 3
		Children: 0
		Flags: Mine, ChildSurface, Mouse, Touch
		Frame Sink Id: FrameSinkId(10, 6)
		Rect: 0,0 2770x1908
		Transform:
		[ +1.0000 +0.0000 +0.0000 -8.0000  
		  +0.0000 +1.0000 +0.0000 -162.0000  
		  +0.0000 +0.0000 +1.0000 -0.0000  
		  +0.0000 +0.0000 +0.0000 +1.0000 ]

For mouse-up we reuse the target found for mouse-down and just transform the point https://cs.chromium.org/chromium/src/content/browser/renderer_host/render_widget_host_input_event_router.cc?type=cs&q=render_widget_host_inpu&g=0&l=396. That logic should be the same for v1 and v2; so it's prob because of different hit-test data/ different transform matrix. Transform is expected to be from parent to child - I'm sure how we get this data for v2? This is what we use for v1 https://cs.chromium.org/chromium/src/components/viz/client/hit_test_data_provider_draw_quad.cc?type=cs&g=0&l=58

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

commit cc346947ff37b367a388f7d5252d1f77d24d1e1b
Author: Xianda Sun <sunxd@chromium.org>
Date: Tue Dec 11 20:21:51 2018

Do not offset location by region's origin in V2 hit testing

V2 hit testing (viz hit testing using cc data) only submits regions with
non-zero origins when the region is clipped by other layers. However, in
these cases, if we offset hit test locations by the "clipped" region's
origin, we will get wrong coordinates for the clipped frame.

Since regions submitted by draw quad data provider can have the offset
factor in the transform, we only disable the offsetting for v2 hit test
in this patch.

Bug: 908923
Change-Id: Ie501db968b94a831b33e27bc3a41d5f2fbc4e7a6
Reviewed-on: https://chromium-review.googlesource.com/c/1359324
Reviewed-by: Ria Jiang <riajiang@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Commit-Queue: Xianda Sun <sunxd@chromium.org>
Cr-Commit-Position: refs/heads/master@{#615643}
[modify] https://crrev.com/cc346947ff37b367a388f7d5252d1f77d24d1e1b/components/viz/host/hit_test/hit_test_query.cc
[modify] https://crrev.com/cc346947ff37b367a388f7d5252d1f77d24d1e1b/content/browser/site_per_process_hit_test_browsertest.cc
[add] https://crrev.com/cc346947ff37b367a388f7d5252d1f77d24d1e1b/content/test/data/frame_tree/page_with_positioned_clipped_iframe.html

Is there more to be done on this issue to fix it?

It should be fixed now. Add label to require verification.

I still can't open the date picker when I tap on the dates (step 2), using Android Canary 73.0.3659.0 (which has c#14), with strict site isolation on a Pixel C, whether or not I enable "Viz Hit-test Draw-quad version".  The date pickers work fine if I disable site isolation.  So I'm assuming there's more work to be done here at least for that part?  Step 4 seems to work fine now.  sunxd@ - can you please double-check?  (I'll reopen for that.)

Thanks for the feedback, as mentioned by Ken in comment #2, the date picker problem seems to exist for a while and is not caused by viz hit test. I think we can find the bug for date picker and merge this issue to that bug.

Hi Ken, are you aware of the issue number of the date picker bug?

sunxd@: I don't know if there is an existing bug for that. In comment 2 when I said it "looks old" I meant that it was on Stable, and so wasn't a recent regression, whereas the input problem was recent. I don't have any reason to think the date picker problem is related to input events.

Tentatively assigning a launch blocker label for site isolation on Android, since this issue seems pretty user visible and breaks core functionality, at least on this site.  sunxd@: would you be able to triage and understand the date picker problem a bit more, to see how widespread it might be?

On devtools emulator, I can reproduce the date picker with VizDisplayCompositor disabled and surface hit test (viz-hit-test-draw-quad and viz-hit-test-surface-layer both disabled), but in other conditions the bug cannot be reproduced. It seems like a bug in surface hit test.

alexmos@: can you confirm that the date picker cannot be open with "Viz Hit-test Draw-quad version" enabled?

riajiang@: can you help find a proper owner for surface hit test issues?

SurfaceHittest is being deprecated (viz-hit-test-draw-quad is on 100% stable on non-cros and ramping up on cros) so if this is only reproducible with SurfaceHittest we prob don't need to worry about it anymore

Oh, I noticed that I've been reproing the date picker issue on a a slightly different URL than what's in the description here: http://www.spicysports.com/ski-rentals/ski-equipment/kids-skis/

Would you mind trying that one?  (I think Daniel might've shared this one before filing this bug.)

This one doesn't show the date picker on initial load, and tapping one of the dates is supposed to bring it up.  With OOPIFs enabled, the date picker doesn't show up, even with both VizDisplayCompositor and VizHitTestDrawQuad enabled (and also when either/both are disabled).  This is on latest canary and dev on two separate devices (Pixel C and Nexus 5).  Turning off OOPIFs makes it work.  Also repros in devtools emulation on Mac canary.

Note that due to our canary/dev trials on Android, to ensure a repro it's best to set strict site isolation to on via chrome://flags/#enable-site-per-process, and to disable it, it's necessary to both turn off chrome://flags/#enable-site-per-process and switch chrome://flags/#site-isolation-trial-opt-out to "opt out".