@caseq for devtools

Are you sure that the "DevTools listening on ws://127.0.0.1:56190/devtools/browser/636653a7-9ad4-4433-b3cd-2ee7e766c1cb" message is actually an error message?

What I think is far more suspicious is this, which comes up a couple of times:
[8400:5780:0910/045440.846:20141765:ERROR:platform_handle_in_transit.cc(54)] DuplicateHandle failed: Access is denied. (0x5)

According to https://bugs.chromium.org/p/chromium/issues/detail?id=876224#c31 this was filed for components_browsertests. Looking at the current try runs I also see this a lot:
DevTools listening on ws://127.0.0.1:50158/devtools/browser/983b637f-cd39-4962-8943-1374ef8f7510
../../components/security_state/content/content_utils_browsertest.cc(101): error: Value of: NavigateToURL(shell(), https_server_.GetURL("/hello.html"))
  Actual: false
Expected: true

I will add some debug information to NavigateToURL.

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

commit 7c89cfb52ac692a432db03e1343b2bd132fb53ea
Author: Dominic Battre <battre@chromium.org>
Date: Tue Sep 11 08:46:03 2018

Debug information for failing navigations

This CL adds some debug output to investigate why we are observing failing
navigations on the Windows 10 bots.

TBR=sky@chromium.org

Bug:  882545 
Change-Id: I4ec3fd453eb7641f79f717c1a48993985ef99681
Reviewed-on: https://chromium-review.googlesource.com/1218902
Commit-Queue: Dominic Battré <battre@chromium.org>
Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
Cr-Commit-Position: refs/heads/master@{#590240}
[modify] https://crrev.com/7c89cfb52ac692a432db03e1343b2bd132fb53ea/content/public/test/content_browser_test_utils.cc

It's very unlikely that the Mojo errors indicate a Mojo bug. It is much more likely that some application code trying to send a handle to another process to which they aren't allowed to send that particular (or possibly any) handle.

John, can this be network service related? I'm assuming if it's on in Win canary, it's on normal test bots?

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

commit ea67191f147d215896e9a19eaad5c29c13464857
Author: Dominic Battre <battre@chromium.org>
Date: Tue Sep 11 15:43:52 2018

Debug information for failing navigations

Unfortunately, the previous CL
(https://chromium-review.googlesource.com/1218902) lacked an important
negation.

TBR=sky@chromium.org

Bug:  882545 
Change-Id: I730dbab7c05b0d67c11be67437b462ac51afd7b3
Reviewed-on: https://chromium-review.googlesource.com/1219750
Reviewed-by: Dominic Battré <battre@chromium.org>
Commit-Queue: Dominic Battré <battre@chromium.org>
Cr-Commit-Position: refs/heads/master@{#590325}
[modify] https://crrev.com/ea67191f147d215896e9a19eaad5c29c13464857/content/public/test/content_browser_test_utils.cc

To circle back on the new debug info per c#6, the failures of our tests ( Issue 883227 ) all have a Net::Error of 0 (OK) but fail to finish the NavigateToURL().

per comment #8, re-assigning to jam@

@rockot: network service only runs on test suites that are prefixed with network_service. So in this case, the flakiness is happening when network service is off.

I see. My comment still stands though, this seems like a bug somewhere in application code dealing with handles.

We might want to find an owner since it's still actively flaking?

I'm investigating this.

 Issue 883227  has been merged into this issue.

Summary of my investigation:
The failure is caused by components_browsertests that call content::NavigateToURL(). This condition is not met: https://cs.chromium.org/chromium/src/content/public/test/content_browser_test_utils.cc?l=58&rcl=0502abaf8bd69dc5b33fc81718c2e0aad85009a2 (navigation succeeded). I suspect that it's because of logic errors in TestNavigationObserver. |last_navigation_succeeded_| is only set on OnDidFinishNavigation(). To my knowledge, there is no guarantee that OnDidFinishNavigation() is called before OnDidStopLoading(), which is the method that exits the loop. We should consider having a TestNavigationObserver that always waits for a navigation to complete and the load to stop (not provide the option to callers and trying to support too many use cases, it makes it hard to reason about the class).

 Issue 893688  has been merged into this issue.

fdoray@, do you have a suggestion for who could do the change you mention in #18? Should it be a random sheriff? An OWNER of something?

I'm looking at it.

I guess the fix would be to replace Wait() with WaitForNavigationFinished() here https://cs.chromium.org/chromium/src/content/public/test/browser_test_utils.cc?type=cs&q=NavigateToURLBlockUntilNavigationsComplete&g=0&l=633

Not sure if it should also wait for load stopped, but perhaps clients expect that too.

One of the previous sheriffs tried that but it broke other tests.

Sheriff here, is there anything I should do about this bug? Or can I move this out of sheriff's queue?

This is one of the blockers of crbug.com/876224(Win10 Tests x64 (dbg) bot is flaky).
Remove the label as other blockers.

Test failures are processed as a part of a dedicated triage, bulk-closing the bugs.