For mushrome, we only need parity with CrOS.

This is a meta bug wrapping all work needed to deliver new-style event-targeting with the display compositor relocated to the viz process. In particular: events need to be targeted correctly including when an OOPIF is occluded by a squashed layer.

Backgrounder: https://docs.google.com/document/d/1f-zVezQvaaQjdbmLj5l2qLfq_yZPR_27H8K2ZxsOJMQ/edit

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

commit 2c346fb3a729d7df6357988b9cbe68c1fa22c7dd
Author: Gary Klassen <gklassen@chromium.org>
Date: Wed Feb 07 18:08:40 2018

Use basic bounds to provide simple hit test information.

Creates a single HitTestRegion for each CompositorFrame based on its bounds.

Use kHitTestAsk flag if it contains an embedded OOPIF - this will cause
HitTestQuery to send a message to resolve the target.

With this approach we can use and test HitTestAggregator independently of
changes in development that will create full HitTestRegion data.

Bug: 672311
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel
Change-Id: I5a17c03cfe18585cdf4780b90c252cc0e7e5a332
Reviewed-on: https://chromium-review.googlesource.com/806688
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Reviewed-by: Robert Kroeger <rjkroege@chromium.org>
Reviewed-by: Ria Jiang <riajiang@chromium.org>
Reviewed-by: kylechar <kylechar@chromium.org>
Commit-Queue: Gary Klassen <gklassen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#535061}
[modify] https://crrev.com/2c346fb3a729d7df6357988b9cbe68c1fa22c7dd/components/viz/client/BUILD.gn
[modify] https://crrev.com/2c346fb3a729d7df6357988b9cbe68c1fa22c7dd/components/viz/client/client_layer_tree_frame_sink.cc
[modify] https://crrev.com/2c346fb3a729d7df6357988b9cbe68c1fa22c7dd/components/viz/client/hit_test_data_provider.h
[add] https://crrev.com/2c346fb3a729d7df6357988b9cbe68c1fa22c7dd/components/viz/client/hit_test_data_provider_simple_bounds.cc
[add] https://crrev.com/2c346fb3a729d7df6357988b9cbe68c1fa22c7dd/components/viz/client/hit_test_data_provider_simple_bounds.h
[add] https://crrev.com/2c346fb3a729d7df6357988b9cbe68c1fa22c7dd/components/viz/client/hit_test_data_provider_simple_bounds_unittest.cc
[modify] https://crrev.com/2c346fb3a729d7df6357988b9cbe68c1fa22c7dd/content/renderer/mus/renderer_window_tree_client.cc
[modify] https://crrev.com/2c346fb3a729d7df6357988b9cbe68c1fa22c7dd/content/renderer/render_thread_impl.cc
[modify] https://crrev.com/2c346fb3a729d7df6357988b9cbe68c1fa22c7dd/ui/aura/hit_test_data_provider_aura.cc
[modify] https://crrev.com/2c346fb3a729d7df6357988b9cbe68c1fa22c7dd/ui/aura/hit_test_data_provider_aura.h
[modify] https://crrev.com/2c346fb3a729d7df6357988b9cbe68c1fa22c7dd/ui/aura/hit_test_data_provider_aura_unittest.cc

Migrating Proj-Mustash-Mus to components Internals>Services>WindowService and Internals>Services>Ash

Currently we have events being sent to the browser, and from the browser to the renderers. I'm assuming this bug only matters for the window-service once we have it directly sending events to renderers. Do I have that right Rob?

Cleaning up old Proj-Mustash labels.

In ws2, does the browser submit its own CFs independent of Ash's CF? And Ash/WS2 embeds the browser which embeds the renderer?

Oop/Ash in either single/multi-process mode will need to resolve the following issue: the viz event targeting in viz host (HitTestQuery running in Ash) will look up the FrameSync corresponding to a particular pixel and use that for event dispatching. HTQ was not designed to be run twice (in ash and browser) so I would expect that event targeting might be confused. I don't recall how we fixed this in mustash. Something will need to be adjusted. I think having ash/ws2 send the events directly might be the cleanest path forward.

In mustash, each oopif used to have a corresponding window in the window-service. So window-service was able to find an OOPIF as the target. In ws2, that is no longer the case I believe.

So in an ideal oop-ash implementation, how are events suppose to be targeted? We must only have one viz host and that suggests only one HTQ.

Right, there should only be a single HTQ in the viz-host (i.e. in ash). HTQ will find the correct target frame-sink. ash would then need to:
 (1) find the closest ancestor frame-sink that is associated with a Window it knows about. HostFrameSinkManager can provide the ancestor information for the frame-sinks.
 (2) dispatch the event, the target frame-sink (OOPIF), and the ancestor Window (RenderWidgetHostViewAura) to the browser. That window (RWHVAura) then should be able to find the correct RenderWidgetHostViewChildFrame from the frame-sink.

When the events reach the browser, will content there know to do the right thing or will it once again try to reach into HTQ for event targeting to the renderers? It's this part of the flow that is my primary concern in an oopash context.

If the frame-sink is correctly plumbed through from ash/ws2 to browser, and browser would not need to reach into HTQ (which it shouldn't do in single-process, and can't do in multi-proc). I think we should fairly strongly restrict access to HTQ from browser in this mode.

I'm super confused. It's not clear to me how the browser routes? It gets the target FrameSinkId?

There are two targeting steps in the browser: first in aura, and then in content. ash/ws2 needs to provide both targets, so the browser doesn't need to do either.