1867688 - [devtools] CORS error results in generic NS_ERROR_INTERCEPTION_FAILED when service worker is active

Status: UNCONFIRMED

(DevTools :: Netmonitor, defect, P3)

Description

[Thayne]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:120.0) Gecko/20100101 Firefox/120.0

Steps to reproduce:

Made a PUT request to a url that did not have CORS headers correctly configured to allow the request from the origin making the request. A service worker was active.

I don't think this request was directly made by a service worker (although I'm not positive), but it is made in an async function that first awaits another request, and that request shows "service worker" in the "Transferred" tab. which is itself odd, because that request is a POST that definitely shouldn't be cached.

In fact all successful requests show "service worker" in the Transferred tab. I suspect because the service worker intercepts all fetches. But I can't see the actual request from the service worker.

Unfortunately, I don't have enough experience with service workers to create a minimal example.

Actual results:

In the network tab the PUT request showed as failed, and the Transferred column said "NS_ERROR_INTERCEPTION_FAILED".

The console had the following errors:

Failed to load ‘<URL>’. A ServiceWorker passed a promise to FetchEvent.respondWith() that rejected with ‘Error: Service Worker failed to fetch <URL>’.
and

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at <URL>. (Reason: CORS request did not succeed). Status code: (null)

Expected results:

• The error message should be more clear that the reason it failed is because the preflight OPTIONS check returned a error response (that also didn't have valid cors headers)
• The preflight OPTIONS request should be visible in the network tab

Of note, chrome provides a much more useful error message:

Access to fetch at '<URL>' from origin 'https://<DOMAIN>' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

and shows the OPTIONS request in the network manager.

Comment 1

[Thayne]

What I think is happening here:

The service worker intercepts all requests, but most of them it just passes through. However, the preflight check is now made by the service worker and so doesn't show up in the network tab. And if it fails with a CORS check, then it shows up as failing in the service work with an opaque error, instead of showing the root cause of the request made by the service worker itself. Maybe there is some way to see the requests made by the service worker itself, but if so, it isn't very discoverable and I wasn't able to find it. And even if that does exist, it would be nice if the devtools detect if the service worker just passed the network request through, and provided better messages in that case.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Networking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Ed Guloien [:edgul]]

I suspect this is Service Workers component. Please throw it back to us if that's not that case.

Comment 4

[Julian Descottes [:jdescottes]]

Thanks for the report, any chance you can share the test page you are using here?

Comment 5

[Thayne]

https://lucid.app/documents/view/b18462f6-cdb0-42f4-a5f6-f4fc937d58c6 is the app where I encountered this issue. But the CORS issue has since been fixed, so it isn't directly reproducable there anymore.

However, there are some related symptoms if you load that site. For example, you can't see the OPTIONS preflight requests for cross origin requests, and the "transferred" column in the network tab shows "service worker" for all requests (after refreshing, on the initial load, the server worker isn't set up yet).

And if I run await fetch('https://example.com/test-post', {method: 'POST', body: 'this is a body', headers: {'contenty-type': 'text/plain'}}); in the developer console I get

Failed to load ‘https://example.com/test-post’. A ServiceWorker passed a promise to FetchEvent.respondWith() that rejected with ‘Error: Service Worker failed to fetch https://example.com/test-post’. e778f729057ab1d88e422871a42e15bac8f51fab213e0192fa05812d37f6c6.js.br:334:386
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://example.com/test-post. (Reason: CORS request did not succeed). Status code: (null).

In the console, and in the network tab it shows NS_ERROR_INTERCEPTION_FAILED for the POST request, and again, doesn't show the OPTIONS request at all.

Comment 6

[Hubert Boma Manilla (:bomsy)]

Hi Thayne,

This (In reply to Thayne from comment #5)

https://lucid.app/documents/view/b18462f6-cdb0-42f4-a5f6-f4fc937d58c6 is the app where I encountered this issue. But the CORS issue has since been fixed, so it isn't directly reproducable there anymore.

Thanks for providing the app link.

However, there are some related symptoms if you load that site. For example, you can't see the OPTIONS preflight requests for cross origin requests, and the "transferred" column in the network tab shows "service worker" for all requests (after refreshing, on the initial load, the server worker isn't set up yet).

The OPTIONS preflight requests not been visible is likely related to a known issue in Bug 1432311 where requests initiated by the service worker is not displayed.
Also the "transferred" column correctly shows "service worker" for all the requests as the service worker starts up quite early, unfortunately this is not really clear to see as the main service worker request is not also displayed when it gets registered. See Bug 1267119.

I'll block this with those bugs, and we can test this again once those are fixed.