Bypass ServiceWorker when the request originates from isolated world.

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 adb2523a114ca4adb00eedd0998559d3eaa2e2df..b8f8f69f972bf9b70f90d5bd53d8c719b0599d9a 100644
--- a/third_party/WebKit/Source/core/loader/DocumentThreadableLoader.cpp
+++ b/third_party/WebKit/Source/core/loader/DocumentThreadableLoader.cpp
@@ -182,6 +182,17 @@ DocumentThreadableLoader::DocumentThreadableLoader(Document& document, Threadabl
             page->chromeClient().didObserveNonGetFetchFromScript();
     }
 
+    // When the request is from different isolated world such as Chrome
+    // extension's content script, we don't send the request to the Service
+    // Worker of the document.
+    if (!m_document.securityOrigin()->isSameSchemeHostPort(securityOrigin())) {

[Mike West, 2015/10/19 11:55:18]

1. This doesn't have anything to do with isolated worlds, does it? You're just
comparing origins.

2. Why 'isSameSchemeHostPort'? What is the expected behavior for sandboxed
documents, for instance?

[horo, 2015/10/19 12:49:32]

I thought that if the fetch (and XHR) is called from the different isolated
world, m_resourceLoaderOptions.securityOrigin is different from the
SecurityOrigin of the document.
When XHR is called from Chrome extension's content script,
m_resourceLoaderOptions.securityOrigin is like "chrome-extension://xxxxx".

Could you please let me know what is the best way to know whether the request is
from the different isolated world?

[kinuko (google), 2015/10/19 14:57:30]

Drive-by... I don't think isolated world has anything to do with security
origin, while it's possible to attach different security origin to an isolated
world. It should be possible to create an isolated script world that has the
same security origin, and it's vague what we want to do in that case from this
patch's description and comment.

+        ResourceRequest newRequest(request);
+        newRequest.setSkipServiceWorker(true);
+        dispatchInitialRequest(newRequest);
+        // |this| may be dead here in async mode.
+        return;
+    }
+
     // If the fetch request will be handled by the ServiceWorker, the
     // FetchRequestMode of the request must be FetchRequestModeCORS or
     // FetchRequestModeCORSWithForcedPreflight. Otherwise the ServiceWorker can