The first issue is working without any CORS policies, still investigating. Please let me know if I should file a separate issue.

yhirano@: Would you mind triaging this?

The first issue is WAI, IIUC. There is no CORS check between the page and the service worker. That response is available on the service worker because ACAO: * is attached, so it will be available on the page as well.

I'm confused by the second problem. Even without editing sw.js (i.e., using https://raw.cm2.pw/Chrome/), opening devtools changes the behavior.

With opening devtools:
"Error: "Script error."" is printed in the TextArea, while "Uncaught ReferenceError: s3cr3t is not defined" is printed in the console.log.

Without opening devtools:
"Error: "Uncaught ReferenceError: s3cr3t is not defined"" is printed in the TextArea.

Is that what you are seeing?

> The first issue is WAI, IIUC. There is no CORS check between the page and the service worker. That response is available on the service worker because ACAO: * is attached, so it will be available on the page as well.

I don't know if I understand it correctly. AFAIK, the errors aren't part of response and shouldn't be available to calling window unless "crossorigin" attribute is specified. Ideall, the behavior is identical but since it has no crossorigin attribute, I guess, it's an implementation flaw. Firefox doesn't expose such error.

> Is that what you are seeing?
Yes, I'm seeing the same behavior.

To clarify #1, the error can be read even without CORS if the referenced script evaluates some input later via eval. The POC above evaluates value entered via prompt value with eval thus the error is available.

However, if we respond with eval with no prompt something like;
```
eval(next); // no prompt and next is not yet defined
```

we cannot read the error. Firefox just returns mutated "script error" message in all cases.

Sorry, I don't understand. Even when service worker is not involved - for example, when we use attached test.html, I see

 ERROR: "Uncaught ReferenceError: s3cr3t is not defined"

Is it problematic?

Deleted: test.html 469 bytes

test.html 469 bytes View Download

Oh, didn't realize that.

> Is it problematic?
Not really.

Then I'm closing this bug as WONTFIX.

Service Worker and CORS are involved in the "fetching" phase. The browser correctly runs the script, so they are not related.

kouhei@ told me that there are (were?) some discussions about error messages from cross-origin scripts, though I actually don't understand. There may be some bugs, but I think it's good to file a new bug with a new repro case.

What about the second issue? It's more about caching, I guess. Once the response is cached, even after unregistering the service worker, we get the same response despite enabling credentialed requests or setting mode to 'no-cors'.
Should I file it as a separate issue?

Re c#13: I don't know if it's problematic. The response for the <script> tag was treated as the same origin in the document, and in that situation, those responses could be cached regardless of service workers.
I assume that it's working as intended.

Okay, I have modified my POC to reflect the issue I'm trying to describe. It's not only related to <script>, it's actually about service worker caching. Please follow along;


1. Navigate to https://raw.cm2.pw/Chrome/ 
2. Open Developer Tools to inspect network traffic
3. Click on 'Fetch x-domain content'
4. Observe response headers of https://bughuntersclub.ipage.com/raw/s3cr3t.js.php (specially, Cache-control header)

The response is printed in the <textarea> and is cached.

5. Close the tab and clear all browsing history from last hour (Ctrl+Shift+Del > Advance > Check all items and click Clear Data)
6. Now, open https://raw.cm2.pw/Chrome/?mode=no-cors (now, we are specifying mode to be 'no-cors')
7. Repeat steps 2 - 4

You should again see the same response because it's cached and is not cleared despite we clearing all browser history from last hour.


I modified the script to accept mode from URL parameter. The default mode is 'cors' and we do not need to specify it. And, FYI, making changes to service worker script (mode: 'no-cors') also has the same effect.

I hope it's, now, more clear. Please let me know if I need to file a separate issue to avoid confusion.

> And, FYI, making changes to service worker script (mode: 'no-cors') also has the same effect.
My apology, I thought changing Service Worker script also yielded the same result but no. That works only if the tab remains open.

Changing mode on 'index.php' did receive the response because the request is being intercepted and changed to be 'cors' (which may be an issue in itself). 

Please close it as invalid and forgive me for my stupid report.

Thanks a lot for looking closely at this issue.

> My apology, I thought changing Service Worker script also yielded the same result but no. That works only if the tab remains open.

Yes, that's the expected behavior. The memory cache is keyed by service worker's id, so unless the page is controlled by a service worker, the cache remains. Even if the service worker is unregistered, it's alive until all clients (tabs) are closed. Only when the active service worker has been changed (ex: a new service worker is installed and it calls skipWaiting()), the key will be changed and the page flushes the cache.

One more question:
What about situations where 'same-origin' or 'no-cors' 'fetch' requests are intercepted and changed with wider scope? For example, I wouldn't expect a 'same-origin' fetch request to respond with cross-domain response (while the opposite is Ok).

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot