kylechar@chromium.org: Your change r617828 caused a regression in a ChromeDriver test. See the issue description for more details. Could you please take a look? Thanks.

I have a pretty idea of what is happening here but I'm not sure how this should be fixed.

r617828 enables OOP-D by default. OOP-D moves the display compositor system from the browser process to the GPU process. Hit testing for OOPIFs is based on data received by the display compositor system. Clients send hit testing data along with CompositorFrames. When the display compositor aggregates CompositorFrames into a display frame to draw, it also aggregates hit test data for hit testing, so that hit testing matches what's drawn. Hit testing happens in the browser process but with OOP-D the aggregated hit test data is in the GPU process. There is some delay between aggregated hit test data being available and the IPC with it arriving in the browser process.

We have C++ test only code, eg. HitTestRegionObserver,  that waits for hit test data from a given FrameSinkId to solve the same type of problem in browser tests. That is much lower level than ChromeDriver though and I'm not really sure what the appropriate way for ChromeDriver to handle this situation is?

I'm adding a few people who worked on viz hit testing but I think we'd need guidance from the ChromeDriver team on what is appropriate here.

So the test already has a "wait" coded to handle system loading delays on Windows.

It seems that ChromeDriver needs actual apis to synchronize on events from within Chrome. One for page load. One for hit testing data being ready.

We could try adding a general wait in this test to see if that could be a temporary work around. However I'd recommend that the ChromeDriver group build themselves those synchronizing apis.

What kind of events signal the hit testing data being ready? Is there any existing example code that waits on these events?

HitTestRegionObserver: content/public/test/hit_test_region_observer.h

This provides the ability for tests to wait for hit test data to have arrived in the browser process.

SitePerProcessHitTestDataGenerationBrowserTest::SetupAndGetHitTestData is an example of a test loading a webpage and then waiting on hit test events.

So I'm not sure how _driver.Load() decides a page has finished loading right now but it sounds like it should wait for hit test to get updated (or maybe some other API is right for that wait)? I don't really have any context here on how Chromedriver works and what is an appropriate API for it.