Gary, Ken, et al: Can you take a look and see if this description sounds right?  I'm wondering if there's an explanation for why this doesn't work without VizHitTestDrawQuad, and if there's a launch target for that feature.  It would be good to know whether more sites might be affected by the underlying issue, whether there's a workaround for them, and whether another fix is needed (depending on how far out this feature is).  Thanks!

+flackr@ and sunxd@

I can't quite explain this, but here are some observations:

1. The problem goes away if you remove the 'will-change:transform' from the SVG element's style. I don't know why that would be, but it could serve as a functional work around.

2. The problem occurs in the intersection of the layer from the out-of-process iframe and the layer from the SVG map. For some reason the quad-based hit testing is sending all the input events to the parent renderer, thinking they are hitting the map. This is strange because even if the SVG layer was on top of the iframe, the browser should notice and fall back to slow-path hit testing to get the correct target. It does not do that.

3. It works correctly in the Viz Hit-test trial, implying that the HitTestRegions are getting it right even though the DrawQuads are giving the wrong result. That is unexpected since I think those are supposed to be the same at this point.

I've been trying to see if any bugs in SurfaceHittest::GetTargetSurfaceAtPointInternal() could account for this problem but so far it seems to be working correctly, and I don't know how the CSS will-change property would have any effect on that.

Looks like the report in  issue 852095  is leading to the same problem.  See comment 19 on that bug for analysis.

I have a change that fixes both this and issue 852905.

https://chromium-review.googlesource.com/c/chromium/src/+/1101579

 Issue 852095  has been merged into this issue.

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

commit e11864948569138c84063f4a704c9945e94f89ad
Author: Ken Buchanan <kenrb@chromium.org>
Date: Fri Jun 15 00:45:13 2018

DrawQuad hit testing should query renderer whenever it hits a Surface

SurfaceHittest finds a target Surface for a point and signals whether
there should be additional hit testing done in the renderer.

Currently this only happens if there is a Surface quad and a
non-Surface DrawQuad under the point, in which case the browser
sets query_renderer in order to get a more confident target.

However, in cases where the Surface is occluded by a RenderPass that
has no DrawQuads in that location, it doesn't set query_renderer
because there does not appear to be a reason to do so. Instead, it
incorrectly thinks the RenderPass is the correct target. This is
problematic because layer squashing can create layers that are much
larger than the elements within them.

This CL changes this behavior so that it always queries when there is a
Surface at the given point.

This will increase the number of asynchronous hit tests that are
performed in general.

Bug:  851802 
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel
Change-Id: I4e878101533e2794fc44cd16f36ea5cd104e59e2
Reviewed-on: https://chromium-review.googlesource.com/1101579
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Commit-Queue: Ken Buchanan <kenrb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#567500}
[modify] https://crrev.com/e11864948569138c84063f4a704c9945e94f89ad/components/viz/service/surfaces/surface_hittest.cc
[modify] https://crrev.com/e11864948569138c84063f4a704c9945e94f89ad/components/viz/service/surfaces/surface_hittest_unittest.cc

Able to reproduce this issue on reported version hence verifying the fix on latest canary 69.0.3461.2 using Windows 10, Ubuntu 14.04 and Mac 10.13.3.

Enabled strict site isolation and by disabling enable-viz-hit-test-draw-quad fro chrome://flags, on navigating to  http://bluewatergis.maps.arcgis.com/apps/MapJournal/index.html?appid=5f1e62621fbb4241b1b58424f7040399. Tooltips and buttons are working on the right side of the graph and able to interact with them successfully. Attaching screencast for reference.

As fix is working as expected adding Verified labels.

Thanks!

Deleted: 851802.mp4 1.6 MB

	851802.mp4 1.6 MB View Download

Agreed-- I can also verify on Windows Canary 69.0.3461.2, both for this and the test page in  https://crbug.com/852095#c19 .  Thanks Ken!

Once this has a chance to bake and ensure there aren't crashes from it, can you request merge to M68?

[Auto-generated comment by a script] We noticed that this issue is targeted for M-67; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-67 label, otherwise remove Merge-TBD label. Thanks.

FWIW, I've also patched r567500 into a local M67 build and it fixes the bug there as well.  Assuming we merge this to M68 and verify it there, I might suggest a proactive merge to M67 as well, just in case there's a respin for another reason.

Setting next action date to Monday to evaluate the M68 merge.

The NextAction date has arrived: 2018-06-18

The fix from #8 appears sufficient and I haven't seen any problems resulting from this on Canary, so requesting merge on 68.

This bug requires manual review: M68 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), kariahda@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Approving merge to M68 branch 3440 based on comment #14. Pls merge. Thank you.

+abdulsyed@ as FYI

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

commit 2f01f779bc0ea9312608fa251f30deb6121c19b9
Author: Ken Buchanan <kenrb@chromium.org>
Date: Mon Jun 18 18:36:16 2018

DrawQuad hit testing should query renderer whenever it hits a Surface

SurfaceHittest finds a target Surface for a point and signals whether
there should be additional hit testing done in the renderer.

Currently this only happens if there is a Surface quad and a
non-Surface DrawQuad under the point, in which case the browser
sets query_renderer in order to get a more confident target.

However, in cases where the Surface is occluded by a RenderPass that
has no DrawQuads in that location, it doesn't set query_renderer
because there does not appear to be a reason to do so. Instead, it
incorrectly thinks the RenderPass is the correct target. This is
problematic because layer squashing can create layers that are much
larger than the elements within them.

This CL changes this behavior so that it always queries when there is a
Surface at the given point.

This will increase the number of asynchronous hit tests that are
performed in general.

Bug:  851802 
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel
Change-Id: I4e878101533e2794fc44cd16f36ea5cd104e59e2
Reviewed-on: https://chromium-review.googlesource.com/1101579
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Commit-Queue: Ken Buchanan <kenrb@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#567500}(cherry picked from commit e11864948569138c84063f4a704c9945e94f89ad)
Reviewed-on: https://chromium-review.googlesource.com/1104821
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Cr-Commit-Position: refs/branch-heads/3440@{#405}
Cr-Branched-From: 010ddcfda246975d194964ccf20038ebbdec6084-refs/heads/master@{#561733}
[modify] https://crrev.com/2f01f779bc0ea9312608fa251f30deb6121c19b9/components/viz/service/surfaces/surface_hittest.cc
[modify] https://crrev.com/2f01f779bc0ea9312608fa251f30deb6121c19b9/components/viz/service/surfaces/surface_hittest_unittest.cc

Able to reproduce this issue on reported version hence verifying the fix on latest beta 68.0.3440.33 using Windows 10, Ubuntu 14.04 and Mac 10.13.3.

Enabled strict site isolation and by disabling enable-viz-hit-test-draw-quad from chrome://flags, on navigating to  http://bluewatergis.maps.arcgis.com/apps/MapJournal/index.html?appid=5f1e62621fbb4241b1b58424f7040399. Tooltips and buttons are working on the right side of the graph and able to interact with them successfully. Attaching screencast for reference.

As fix is working as expected adding Verified labels.

Thanks!

Deleted: 851802_M68.mp4 3.1 MB

	851802_M68.mp4 3.1 MB View Download

 Issue 854558  has been merged into this issue.

Requesting post-stable merge to M67, given discussion with govind@ and on https://bugs.chromium.org/p/chromium/issues/detail?id=810843#c41.  This fix will also address the cases reported in  issue 852095  and  issue 854558 .

Note that I have already verified the fix on a local M67 branch in comment 12.  The fix itself is quite small and safe, and the main downside is increasing the number of cases where an asynchronous hit test is needed.  The fix has been baking on Canary/Dev since 69.0.3461.0 and on Beta since yesterday's 68.0.3440.33.  (I see no new crashes from it on Beta, and the Beta fix was verified in comment 19.)

Approving merge to M67 branch 3396 based on comment #21. Please merge. Thank you.

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

commit 14a72d4ff702d3fc30b770c0ef9bcb6043abb176
Author: Ken Buchanan <kenrb@chromium.org>
Date: Thu Jun 21 22:13:10 2018

DrawQuad hit testing should query renderer whenever it hits a Surface

SurfaceHittest finds a target Surface for a point and signals whether
there should be additional hit testing done in the renderer.

Currently this only happens if there is a Surface quad and a
non-Surface DrawQuad under the point, in which case the browser
sets query_renderer in order to get a more confident target.

However, in cases where the Surface is occluded by a RenderPass that
has no DrawQuads in that location, it doesn't set query_renderer
because there does not appear to be a reason to do so. Instead, it
incorrectly thinks the RenderPass is the correct target. This is
problematic because layer squashing can create layers that are much
larger than the elements within them.

This CL changes this behavior so that it always queries when there is a
Surface at the given point.

This will increase the number of asynchronous hit tests that are
performed in general.

Bug:  851802 
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel
Change-Id: I4e878101533e2794fc44cd16f36ea5cd104e59e2
Reviewed-on: https://chromium-review.googlesource.com/1101579
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Commit-Queue: Ken Buchanan <kenrb@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#567500}(cherry picked from commit e11864948569138c84063f4a704c9945e94f89ad)
Reviewed-on: https://chromium-review.googlesource.com/1110899
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Cr-Commit-Position: refs/branch-heads/3396@{#786}
Cr-Branched-From: 9ef2aa869bc7bc0c089e255d698cca6e47d6b038-refs/heads/master@{#550428}
[modify] https://crrev.com/14a72d4ff702d3fc30b770c0ef9bcb6043abb176/components/viz/service/surfaces/surface_hittest.cc
[modify] https://crrev.com/14a72d4ff702d3fc30b770c0ef9bcb6043abb176/components/viz/service/surfaces/surface_hittest_unittest.cc

Thanks Ken!  I have verified that the repro steps for this bug,  issue 852095  (from comment 19 of that bug), and  issue 854558  (from comment 8 of that bug) are all working in the staging build of 67.0.3396.99 on Mac.

Able to reproduce this issue on reported version hence verifying the fix on latest stable 67.0.3396.99 using Windows 10, Linux and Mac 10.13.3.

Enabled strict site isolation and by disabling enable-viz-hit-test-draw-quad from chrome://flags, on navigating to  http://bluewatergis.maps.arcgis.com/apps/MapJournal/index.html?appid=5f1e62621fbb4241b1b58424f7040399. Tooltips and buttons are working on the right side of the graph and able to interact with them successfully. Attaching screencast for reference.

As fix is working as expected adding Verified labels.

Thanks!

Deleted: 851802_M67.mp4 3.3 MB

	851802_M67.mp4 3.3 MB View Download

Verified this issue on 67.0.3396.99/10575.58.0 stable channel candy using steps mentioned in comment#0. Able to see tooltips when hovered and able to click buttons. Attaching screenshot for reference.

Thanks! 

Deleted: 851802_CrOS.png 175 KB

	851802_CrOS.png 175 KB View Download

Update: Chrome 67.0.3396.99 is now available on the stable channel with the fix.  You can trigger an update manually by visiting chrome://chrome.