ServiceWorker doesn't catch routes in Firefox only

[LeBenLeBen]

Describe the bug

MSW properly mock routes in Chrome and Safari, but doesn't in Firefox.

Environment

• msw: 0.19.3
• nodejs: 12.14.0
• npm: 6.14.2
• firefox: 77.0.1

To Reproduce

Here’s my mocks.js file:

import { setupWorker, rest } from 'msw';

const worker = setupWorker(
  rest.get('http://localhost:3000/api/user/:id/', (req, res, ctx) => {
    const { id } = req.params;

    return res(
      ctx.status(202, 'Mocked'),
      ctx.json({
        id: id,
      })
    );
  })
);

worker.start();

The request is made with Axios within a Vue.js generated with Vue CLI and using TypeScript. It basically looks like this:

this.axios.defaults.baseURL = 'http://localhost:3000/api';
this.axios.defaults.headers.common['Accept'] = 'application/json';
// ...
this.axios.get(`/user/${id}`);

I tried to put some logs in the ServiceWorker and it seems to not catch this request at all while seeing others such as assets.

I'm testing in HTTP but I have checked the parameter to enable SW in HTTP in the devtools. I have also cleared the SW after every change in about:debugging to be sure it was up-to-date.

Expected behavior

The request should be mocked in Firefox just like it does in Chrome and Safari.

Screenshots

Firefox console:

Chrome console:

[kettanaito]

Hey, @LeBenLeBen. Thanks for reporting this.

I've tried to reproduce this behavior using the REST - Params example in Firefox 77.0.1 (64-bit). However, instead of Request failed exception I got #223. It appears that Firefox fails to constructs a regular expression with a named captured group. There are two concerns I have:

1. Why it prints a different error message in your case? Since your path also includes a parameter /:id, it also produces a named captured group, which seems not to be supported in Firefox.
2. Why node-match-path doesn't compile named captured groups to a backward-compatible implementation. It uses @babel/plugin-transform-named-capturing-groups-regex in babel.config.js for that very purpose. It looks like that transformation doesn't happen.

[kettanaito]

Meanwhile, may I please ask you to remove the /:id path parameter (from both request handler and actual request URL) and see if the request gets intercepted and mocked properly?

That way we can triage where the problem is. Thanks.

[LeBenLeBen]

Thanks for replying so quickly!

I hard coded the URL to mock to be http://localhost:3000/api/user/1, cleaned the SW and tried again but the problem is still the same (also still works in Chrome).

What is weird is that if I add some logging in the SW, at the very beginning of the fetch listener:

console.warn('Catch fetch for', request.url);

The URL I’m trying to mock doesn't event show up in the logs:

Catch fetch for http://localhost:3000/ mockServiceWorker.js:75:11
Catch fetch for http://localhost:3000/js/chunk-vendors.js mockServiceWorker.js:75:11
Catch fetch for http://localhost:3000/js/app.js mockServiceWorker.js:75:11
[HMR] Waiting for update signal from WDS... log.js:24
Catch fetch for http://localhost:3000/favicon.ico mockServiceWorker.js:75:11
Catch fetch for http://localhost:3000/js/home.js mockServiceWorker.js:75:11
Catch fetch for http://localhost:3000/img/logo.6611ba71.svg mockServiceWorker.js:75:11
Catch fetch for http://localhost:3000/fonts/ProximaNova-Bold.70f035d0.woff2 mockServiceWorker.js:75:11
Catch fetch for http://localhost:3000/fonts/ProximaNova-Regular.89e103e9.woff2 mockServiceWorker.js:75:11
[MSW] Mocking enabled. index.js:173
XHR GET http://192.168.1.111:3000/sockjs-node/info?t=1592387419699 [HTTP/1.1 200 OK 0ms]
XHR GET http://localhost:3000/api/user/1 [HTTP/1.1 404 Not Found 1ms]

Isn't supposed to show up here as other resources? It's like Firefox doesn't let that request go into the SW at all.

[kettanaito]

That's strange.

May I please ask you to add console.log(request) expression in your <PUBLIC_DIR>/mockServiceWorker.js file on this line:

msw/src/mockServiceWorker.js

Line 74 in 638874a

If that doesn't print anything out, it's either SW is not properly registered, or there's an issue between browser and the worker. If it does print something out (which I hope), I'd recommend checking what happens later, during the response:

msw/src/mockServiceWorker.js

Lines 83 to 94 in 638874a

	const client = await event.target.clients.get(clientId)
	if (
	// Bypass mocking when no clients active
	!client ||
	// Bypass mocking if the current client has mocking disabled
	!clients[clientId] ||
	// Bypass mocking for navigation requests
	request.mode === 'navigate'
	) {
	return resolve(getOriginalResponse())
	}

In this part of the worker we check if there's any client present, and that client has mocking enabled, only then we attempt to query for the mocked response from the client.

Sorry for asking to do this, I cannot seem to reproduce it in Firefox myself. I'm testing using the REST Query parameters example.

[LeBenLeBen]

I was able to make Firefox mock the request by running fetch('http://localhost:3000/api/user/1') directly in the browser console.

I checked both requests to find differences, and basically the one that fails is an XMLHttpRequest whereas the one that works is done with Fetch.

This leaded me to find that XHR within SW are not supported in Firefox apparently, which match with my logs not outputting the XHR request at all from the SW.

I guess we'll have to either use Fetch or Chrome then 😅

[kettanaito]

Thanks for finding that, @LeBenLeBen! I didn't know that Firefox limitation. Glad that the issue could be resolved :)

[Thane2376]

@kettanaito it seems this is not resolved still? do you have any workaround for Firefox to make it work?

[LeBenLeBen]

@Thane2376 It’s a browser limitation, no workaround is possible, you should either use Fetch or another browser.

[kettanaito]

@Thane2376, as rightfully pointed, it’s a Firefox-specific limitation. We will not provide any workarounds for that, as we don’t ship browser- and framework-specific logic.

[Chris-Loughnane]

We had a situation where FF would not redirect and Chrome did which caused us problems that had us scratching our heads. Our setup had an XHR within a service worker. Thanks for your post and cause analysis, it helped us track down the issue.

We also found, that although the redirect would not work on one tab in FF it did on any other tab instance. If we get time we'll try and figure out why that's the case.