Bypass ServiceWorker when the request originates from isolated world.

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

 /*
  * Copyright (C) 2011, 2012 Google Inc. All rights reserved.
  * Copyright (C) 2013, Intel Corporation
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions are
  * met:
  *
  *     * Redistributions of source code must retain the above copyright
  * notice, this list of conditions and the following disclaimer.
@@ skipping 164 matching lines @@
     //     recorded here.
     // - ThreadableLoader w/ non-GET request is only created from javascript
     //   initiated fetch.
     //   - Some non-script initiated fetches such as WorkerScriptLoader also use
     //     ThreadableLoader, but they are guaranteed to use GET method.
     if (request.httpMethod() != "GET") {
         if (Page* page = m_document.page())
             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
     // return a opaque response which is from the other origin site and the
     // script in the page can read the content.
     //
     // We assume that ServiceWorker is skipped for sync requests and non-HTTP
     // familiy requests by content/ code.
     if (m_async && !request.skipServiceWorker() && request.url().protocolIsInHTTPFamily() && m_document.fetcher()->isControlledByServiceWorker()) {
         ResourceRequest newRequest(request);
@@ skipping 670 matching lines @@
         return DoNotAllowStoredCredentials;
     return m_resourceLoaderOptions.allowCredentials;
 }
 
 SecurityOrigin* DocumentThreadableLoader::securityOrigin() const
 {
     return m_securityOrigin ? m_securityOrigin.get() : m_document.securityOrigin();
 }
 
 } // namespace blink