Now I'm confused because a lot of the failure links in Flakiness Dashboard do not contain failures.

Still quite a lot of flakes (although it's a bit hard to find them from the flakiness dashboard) -- look for the black ones.

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

commit f5c1ca2bcc7f2cecd48866670dd7f0ddf3c0f24c
Author: mgiuca <mgiuca@chromium.org>
Date: Mon Feb 20 02:16:21 2017

Disable ProcessManagerBrowserTest.FrameClassification due to flake.

BUG=693287
TBR=rob@robwu.nl,rdevlin.cronin@chromium.org

Review-Url: https://codereview.chromium.org/2698383002
Cr-Commit-Position: refs/heads/master@{#451543}

[modify] https://crrev.com/f5c1ca2bcc7f2cecd48866670dd7f0ddf3c0f24c/chrome/browser/extensions/process_manager_browsertest.cc

Test disabled. PTAL Rob, Devlin.

https://build.chromium.org/p/chromium.mac/builders/Mac10.11%20Tests/builds/8241/steps/browser_tests%20on%20Mac-10.11/logs/ProcessManagerBrowserTest.FrameClassification shows 4x:
../../chrome/browser/extensions/process_manager_browsertest.cc:510: Failure
Value of: pm->GetAllFrames().size()
  Actual: 4
Expected: IfExtensionsIsolated(3, 2)
Which is: 3
../../chrome/browser/extensions/process_manager_browsertest.cc:511: Failure
Value of: pm->GetRenderFrameHostsForExtension(extension1->id()).size()
  Actual: 3
Expected: 2u
Which is: 2

Based on this message, I guess that either of the following has happened:

- content::NavigateIframeToURL returns earlier (faster) than before the flakiness occurred, or

- ProcessManager::UnregisterRenderFrameHost is called too late after a frame navigates.
  In the current source, ExtensionWebContentsObserver::DidFinishNavigation is the caller for this event.
6987a2dae3753b2adf9942342bc4b30faf206a39 changed this logic, which happened only 9 days before the approximate time from the initial report.

jam, could your change have caused the flakiness? And if so, do you know what happened?

 Issue 693969  has been merged into this issue.

This might be due to pending delete RFH's -- it was the source of another test flake in the same file.

During a cross-process navigation, RenderFrameDeleted won't occur until after we hear back from the frame's unload handler, but load stop can beat the unload handler (since load in the new process is happening in parallel with unload in the old process).

It's possible to verify this theory by forcing a slow unload handler (e.g. one that does a synchronous XHR to /slow?1) just before navigating a frame. That should make the race resolve unfavorably, turning the flake into 100% failure.