Findit identified the culprit r552589 with confidence 70.0% in the config "chromium.chromiumos / linux-chromeos-rel"
based on the flakiness trend:

https://findit-for-me.appspot.com/waterfall/flake?key=ag9zfmZpbmRpdC1mb3ItbWVy3AELEhdNYXN0ZXJGbGFrZUFuYWx5c2lzUm9vdCKlAWNocm9taXVtLmNocm9taXVtb3MvbGludXgtY2hyb21lb3MtcmVsLzcxMjkvaW50ZXJhY3RpdmVfdWlfdGVzdHMvUTNKdmMzTlRhWFJsVTNWaVpuSmhiV1V2UkhKaFowRnVaRVJ5YjNCQ2NtOTNjMlZ5VkdWemRDNUVjbUZuU1cxaFoyVkdjbTl0UkdsellYQndaV0Z5YVc1blJuSmhiV1V2TUE9PQwLEhNNYXN0ZXJGbGFrZUFuYWx5c2lzGAEM


Automatically posted by the findit-for-me app (https://goo.gl/Ot9f7N).
Flake Analyzer is in beta.
Feedback is welcome! Please use component Tools>Test>FindIt>Flakiness

CL to disable the tests on CrOS: https://crrev.com/c/1024233

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

commit 0367affc080cd469434aee976e6482aa235a8290
Author: Lukasz Anforowicz <lukasza@chromium.org>
Date: Mon Apr 23 18:13:48 2018

Disable drag-and-drop tests that are flaky on CrOS with OOPIFs.

Bug: 835572, 835573
Change-Id: I76a2d7407d376a92c0dea7649bc877349d862f2f
Reviewed-on: https://chromium-review.googlesource.com/1024233
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/heads/master@{#552752}
[modify] https://crrev.com/0367affc080cd469434aee976e6482aa235a8290/chrome/browser/ui/views/drag_and_drop_interactive_uitest.cc

 Issue 835851  has been merged into this issue.

Looking at  issue 835851 , and seeing SurfaceHitTestReadyNotifier::WaitForSurfaceReady() in the stacktrace, and ChromeOS, I'm wondering if the test failure might be Viz-related.

+jonross@ and fsamuel@ who might know more.

We aren't running Viz on ChromeOS right now. So that shouldn't be affecting OOPIFs in interactive_ui_tests.

SurfaceHitTestReadyNotifier::WaitForSurfaceReady should be working fine in that suite.

Thanks for the confirmation ... perhaps the test is waiting on a surface that is *never* ready, and so it times out.

Findit identified the culprit r552589 with confidence 70.0% in the config "chromium.chromiumos / linux-chromeos-rel"
based on the flakiness trend:

https://findit-for-me.appspot.com/waterfall/flake?key=ag9zfmZpbmRpdC1mb3ItbWVy3AELEhdNYXN0ZXJGbGFrZUFuYWx5c2lzUm9vdCKlAWNocm9taXVtLmNocm9taXVtb3MvbGludXgtY2hyb21lb3MtcmVsLzcxMjkvaW50ZXJhY3RpdmVfdWlfdGVzdHMvUTNKdmMzTlRhWFJsVTNWaVpuSmhiV1V2UkhKaFowRnVaRVJ5YjNCQ2NtOTNjMlZ5VkdWemRDNUVjbUZuU1cxaFoyVkdjbTl0UkdsellYQndaV0Z5YVc1blJuSmhiV1V2TUE9PQwLEhNNYXN0ZXJGbGFrZUFuYWx5c2lzGAIM


Automatically posted by the findit-for-me app (https://goo.gl/Ot9f7N).
Feedback is welcome! Please use component Tools>Test>FindIt>Flakiness

So in the traces that contain SurfaceHitTestReadyNotifier::WaitForSurfaceReady they are waiting on surfaces which are never ready.

However another source of flaking is that they often are never waiting.

DragAndDropBrowserTest::NavigateNamedFrame calls WaitForChildFrameSurfaceReady, which also contains an early exit if the view is not a RenderWidgetHostViewChildFrame.

I'm working on building a new hit test region testing api, and turned that silent early exit into a CHECK(false). Which these tests trigger: 

https://ci.chromium.org/p/chromium/builders/luci.chromium.try/linux_chromium_rel_ng/104467

It's likely that these tests need to be reviewed to find the correct frames to wait on. Either that, or wait until Viz hit testing lands, and the new hit testing api can be used.

Is there a chance this has been resolved by your recent work on deflaking WaitForHitTestDataOrChildSurfaceReady?