service worker: Enable nav preload network fallback test under NetworkService.

The test was flakily failing because the test server was seeing three
requests during the navigation instead of the expected one or two.

Analysis of the bug showed this was an expected possible path of the
browser cache, which happens when there are concurrent requests and one
of them is cancelled. The cache thinks it should not continue and
restarts the ongoing request, which can cause an extra network request.

This test hit the path because it issues a navigation preload request
and immediately cancels it and starts the normal navigation request.

Since developers are advised not to activate navigation preload and then
not use it,[1] we can keep this behavior.

It's unknown though why r585201 caused this flake to appear when it
didn't appear before. It's looks like it should have always been
possible.

[1] https://developers.google.com/web/updates/2017/02/navigation-preload#using_the_preloaded_response

Bug: 876911
Cq-Include-Trybots: luci.chromium.try:linux_mojo
Change-Id: I42eca116bcfffbb3c622d040343aa62980b83ee5
Reviewed-on: https://chromium-review.googlesource.com/1189514
Commit-Queue: Matt Falkenhagen <falken@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586442}

content/browser/service_worker/service_worker_browsertest.cc

@@ -1998,21 +1998,32 @@ IN_PROC_BROWSER_TEST_F(ServiceWorkerNavigationPreloadTest, NetworkFallback) {
   EXPECT_EQ("Hello world.",
             LoadNavigationPreloadTestPage(page_url, worker_url, "PASS"));
 
-  // The page request must be sent once or twice:
+  // The page request can be sent one, two, or three times.
   // - A navigation preload request may be sent. But it is possible that the
   //   navigation preload request is canceled before reaching the server.
   // - A fallback request must be sent since respondWith wasn't used.
+  // - A second fallback request can be sent because the HttpCache may get
+  //   confused when there are two concurrent requests (navigation preload and
+  //   fallback) and one of them is cancelled (navigation preload). It restarts
+  //   the ongoing request, possibly triggering another network request (see
+  //   https://crbug.com/876911).
   const int request_count = GetRequestCount(kPageUrl);
-  ASSERT_TRUE(request_count == 1 || request_count == 2);
+  ASSERT_TRUE(request_count == 1 || request_count == 2 || request_count == 3)
+      << request_count;
   if (request_count == 1) {
     // Fallback request.
     EXPECT_FALSE(HasNavigationPreloadHeader(request_log_[kPageUrl][0]));
-  } else if (request_count == 2) {
+  } else {
     // Navigation preload request.
     ASSERT_TRUE(HasNavigationPreloadHeader(request_log_[kPageUrl][0]));
     EXPECT_EQ("true", GetNavigationPreloadHeader(request_log_[kPageUrl][0]));
     // Fallback request.
     EXPECT_FALSE(HasNavigationPreloadHeader(request_log_[kPageUrl][1]));
+
+    // Additional fallback request when the HttpCache reissues a network
+    // request.
+    if (request_count == 3)
+      EXPECT_FALSE(HasNavigationPreloadHeader(request_log_[kPageUrl][2]));
   }
 }
 

testing/buildbot/filters/mojo.fyi.network_content_browsertests.filter

@@ -25,10 +25,6 @@
 # https://crbug.com/827318
 -RenderThreadImplBrowserTest.NonResourceDispatchIPCTasksDontGoThroughScheduler
 
-# Flaky, temporarily disabling while investigating.
-# https://crbug.com/876911
--ServiceWorkerNavigationPreloadTest.NetworkFallback
-
 # NOTE: if adding an exclusion for an existing failure (e.g. additional test for
 # feature X that is already not working), please add it beside the existing
 # failures. Otherwise please reach out to network-service-dev@.