Ns error interception failed

Hi. @mylesdawson. Thanks for reporting this.

I’ve followed the steps above and was able to reproduce this in Firefox. It appears you are making a GraphQL request. Since it’s not handled with MSW, you expect it to hit an actual endpoint and be performed as-is.

In the example project I’m trying this, my GraphQL endpoint and the address of my app differ.

• App runs at http://localhost:3002
• GraphQL endpoint is http://localhost:3000

When I follow those steps I also see a few console errors in the «Console» tab of the DevTools:

[MSW] Failed to mock a "POST" request to "http://localhost:3000/graphql": TypeError: NetworkError when attempting to fetch resource.

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://localhost:3000/graphql. (Reason: CORS request did not succeed).

Failed to load ‘http://localhost:3000/graphql’. A ServiceWorker passed a promise to FetchEvent.respondWith() that resolved with non-Response value ‘undefined’.

Response mode seems to have no effect on this issue: it’s reproducible either way (FireFox 84.0.2 (64-bit), 85.0.2 (64-bit)).

I also see the NS_ERROR_INTERCEPTION_FAILED state of the request in the «Transferred» column of the «Network» tab, just as you’ve described.

Why is this happening?

I suspect you have a similar setup to mine: your app’s address and your GraphQL address differ. When you attempt to perform a bypassed (not mocked) request to your actual GraphQL endpoint, you get a CORS violation.

Can you please check the console errors and report if there are any?

How to fix this?

Here are some guidelines on how to avoid CORS errors on localhost.

If CORS is the reason, the error isn’t specific to the library: you cannot request external resources from localhost, CORS won’t allow that. You’d have to set up your app to enable such requests while you’re developing locally. Above I’ve linked but one example of how to do that, you can also find other online.

In the case it’s not it

MSW will not intercept the request, the server will respond with the correct status and data

Note that MSW intercepts all requests in the worker, sends them to the client where it decides whether to mock a request or not. This is intentional behavior, otherwise, we won’t be able to process all traffic, granting a predictable mocking. Yes, one of the surfaces that would error during a failed request will be the worker, but there’s usually more info to that (like the CORS errors indicating what is the real culprit).

In the case if what I described above isn’t applicable to your case, please provide us with the following information:

• How do you make a request (exact client calls)?
• What are the addresses of your app and your GraphQL endpoint you try to hit (the not mocked one)?
• Can you provide a reproduction repository confirming the issue is not CORS?

This article is protected, probably because it was spammed repeatedly. To edit protected pages, bug me to try to make the spam protection better, or register and contact me.

These are primarily notes
It won’t be complete in any sense.
It exists to contain fragments of useful information.

0x80004005 (NS ERROR FAILURE)

…is a very general-purpose error (not even just in mozilla)

When scripting triggers it, then the error also usually points to a more specific problem.
To figure out what failed, look for the origination function.

For example, in:

[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE)
[nsIDOMHTMLSelectElement.selectedIndex]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" 
location: "JS frame ::

…it’s

nsIDOMHTMLSelectElement.selectedIndex

, a good thing to search for.

This particular error was caused by trying to set an out-of-bounds selectedIndex on a <SELECT> drop-down .

nsIXMLHttpRequest.*

XmlHTTPRequest-related errors will usually occur in either nsIXMLHttpRequest.open or nsIXMLHttpRequest.send

The specific error is often the best indication of the problem.

The actual problem to fix (often in the scripting logic) is regularly one of:

• stale references, often between documents , or the browser got confused about when it should clean up. For example, if the document an XHR was created in does not exist anymore, or using an old reference to a new embedded plugin object (e.g. video)

• that you violated the specs or did something nonsensical, e.g. trying to send() more than once(verify) or trying to set headers after sending data (verify)

• Use of firebug:
  • If you are using firebug, you should be aware that there are older versions that did not handle XHR in frames well. Firebug would be the sole cause of the last mentioned error.
  • triggering XHR from the firebug command line is sandboxed, and may cause this in certain cases

• trying cross-domain XHR, or using an absolute URL (verify)

You could even look at the Firefox XHR source code, e.f. for send(), to see what cases trigger this error.

TODO: Read:

• http://www.fleegix.org/articles/2006/10/21/xmlhttprequest-and-0x80004005-ns_error_failure-error

Unsorted

0x80040111 (NS ERROR NOT AVAILABLE)

Reason

The direct reason is a missing object attribute — you are probably expecting an attribute to be present on an object when it is not always.

When this happens around an XMLHttpRequest, one of the likeliest causes around is an onerror handler that tries to read the result’s status (or statusText).

The W3 specs tell you that you shouldn’t try to read status in the onerror handler because for some problems it may not be set, and that accessing it must (!) then lead to an exception raise.

In other words, this error is then correct behaviour.

This error is more specific to Gecko (Firefox, Mozilla) because it adheres to those specs closer to the letter in this regard.
So for portable code you want to adhere to that always.

The underlying cause is often that the browser never got a response with a HTTP status to parse out, for example because:

• a connection broke before receiving a response at all, e.g. because of some connectivity problem

• a request was broken off on the client

• an ongoing AJAX call is canceled by page unload
  • (another somewhat common form of this is when you trigger AJAX from an input form that also causes a page-reload-style submission of the calling page (often a form with a submit-type button))

• or sometimes a (seriously) malformed server response, such as
  • deformed data made by a dynamic script
  • no data at all (no HTTP headers, no body)

Fix

If this happens in your own handler code, and you can’t or don’t want to remove the status check, the simplest workaround is usually to wrap this read in a try-catch, since the error handling would often be «oh well, forget it then» code anyway.

If you use XHR from some library (and implicitly its error handler), it’s a bug in that library that has not yet been fixed, so search around for a newer version, bother its creator, and/or fix it yourself.

If such a library it lets you write your own callbacks and its documentation didn’t warn you about this, you might wish to bother them about that — it’s nice to be able to have code that can react to this if and when it chooses to.

When caused by the form submission problem, you can usually avoid it.
One solution is to use only a <button>, <input type=»button»>, or anything else that looks clickable enough but does not submit the form (like a submit button would), so that the only event is the AJAXing.

See also

• http://www.w3.org/TR/XMLHttpRequest/ (the «The XMLHttpRequest Object» section)
• https://bugzilla.mozilla.org/show_bug.cgi?id=238559