Fix foreign fetch intercepting CORS preflighted requests if preflight was in cache.

third_party/WebKit/Source/core/loader/DocumentThreadableLoader.cpp

Index: third_party/WebKit/Source/core/loader/DocumentThreadableLoader.cpp
diff --git a/third_party/WebKit/Source/core/loader/DocumentThreadableLoader.cpp b/third_party/WebKit/Source/core/loader/DocumentThreadableLoader.cpp
index e6aa7c47fd9a818012271e5280e0167f6aa41045..691e47279cea6bf98ba90229126e1bce3ae8868f 100644
--- a/third_party/WebKit/Source/core/loader/DocumentThreadableLoader.cpp
+++ b/third_party/WebKit/Source/core/loader/DocumentThreadableLoader.cpp
@@ -369,6 +369,16 @@ void DocumentThreadableLoader::makeCrossOriginAccessRequest(
     prepareCrossOriginRequest(crossOriginRequest);
     loadRequest(crossOriginRequest, crossOriginOptions);
   } else {
+    // Explicitly set the SkipServiceWorker flag here. Even if the page is not
+    // controlled by a SW at this point, a new SW may be controlling the page

[falken, 2016/12/20 05:27:42]

so we only get to this point when the page is not controlled by a SW?

Can the comment be revised to say "Although the page is not controlled by a SW
at this point"?

[Marijn Kruisselbrink, 2016/12/20 17:28:28]

Yes, ::start() only ends up calling dispatchInitialRequest (which then calls
makeCrossOriginAccessRequest) when it decides that the page is not controlled by
a SW (otherwise all the CORS logic is bypassed).
Done

+    // when this request gets send later. We should not send the actual request

[falken, 2016/12/20 05:27:42]

sent later

[Marijn Kruisselbrink, 2016/12/20 17:28:28]

Done

+    // to the SW. https://crbug.com/604583
+    // Similarly we don't want any requests that could involve a CORS preflight
+    // to get intercepted by a foreign fetch service worker, even if we have the
+    // result of the preflight cached already. https://crbug.com/674370

[falken, 2016/12/20 05:27:42]

Not sure I understand the bug.. the cache was surviving between layout test
iterations? Could you add a comment to the bug for future reference about the
cause?

[Marijn Kruisselbrink, 2016/12/20 17:28:28]

Yes, that seems to be what was happening. Not sure if it is expected or not that
the preflight cache sometimes survives. Added a comment to the bug.

+    crossOriginRequest.setSkipServiceWorker(
+        WebURLRequest::SkipServiceWorker::All);
+
     bool shouldForcePreflight =
         request.isExternalRequest() ||
         InspectorInstrumentation::shouldForceCORSPreflight(m_document);
@@ -916,12 +926,6 @@ void DocumentThreadableLoader::loadActualRequest() {
 
   clearResource();
 
-  // Explicitly set the SkipServiceWorker flag here. Even if the page was not
-  // controlled by a SW when the preflight request was sent, a new SW may be
-  // controlling the page now by calling clients.claim(). We should not send
-  // the actual request to the SW. https://crbug.com/604583
-  actualRequest.setSkipServiceWorker(WebURLRequest::SkipServiceWorker::All);
-
   prepareCrossOriginRequest(actualRequest);
   loadRequest(actualRequest, actualOptions);
 }