create-react-app: Hot module reloading with proxy not working in Firefox but works in Chrome

Don’t close it stale bot! 😇

As a temporary workaround, using the manual proxy config instead of using the proxy entry in package.json worked for me.

@andygock this is happening because you did close your open WebSocket. Try closing them socket.close(); and retry.

@andygock this is happening because you did close your open WebSocket. Try closing them socket.close(); and retry.

@Developerayo Where and how should I do this in a create-react-app project? I’m not using any WebSocket in my app itself, so I’m guessing the sockets are part of the HMR implementation.

There is an entry in the Mozilla issue tracker: https://bugzilla.mozilla.org/show_bug.cgi?id=1536843

i have found that oddly it works the first time, but not again until i restart firefox.

Yeah on closer inspection it might not be related to the redirect. Sometimes it works and sometimes it doesn’t but I can’t seem to find a pattern to when it works.

Firefox 60.6.1 ESR - works okay

Just tested this and can confirm this release has no issues.

Bumping to keep the issue from closing. Still using the manual proxy workaround.

Hot reloading functionality is always here https://github.com/facebook/create-react-app/blob/2add1288358f5d8ed6c162af32530255087153ce/packages/react-scripts/config/webpackDevServer.config.js#L63-L68 this endpoint already used by webpackHotDevClient https://github.com/facebook/create-react-app/blob/2add1288358f5d8ed6c162af32530255087153ce/packages/react-dev-utils/webpackHotDevClient.js#L66-L67 and it’s not a part of user defined functionality. What is the reason for hiding it behind proxy?

For example, it may be excluded (before accept header analyzing) by changing mayProxy method to

  // If proxy is specified, let it handle any request except files in the public folder and WebpackDevServer endpoint.
  function mayProxy(pathname) {
    const maybePublicPath = path.resolve(appPublicFolder, pathname.slice(1));
    const isPublicFileRequest = fs.existsSync(maybePublicPath);
    const isWdsEndpointRequest = pathname.startsWith('/sockjs-node'); // used by webpackHotDevClient
    return !(isPublicFileRequest || isWdsEndpointRequest);
  }

@mrmckeb @iansu , what do you think?

There is an entry in the Mozilla issue tracker:

Following up from that bug (which was just resolved as invalid, because it seems like a bug in sockjs-client:

…mozregression pointed to a bug 1417463. That bug changed default accept header and further testing showed that it’s server side issue. For some reason, server goes mad when “text/html” is missing in the accept header and after few frames it sends some unexpected HTTP response over the websocket connection.

So possibly a down-stream sockjs-client issue? I’ll file a bug over there.

On creating a blank project using e.g npx create-react-app test - no problems in both browsers. There may be something going on with my app as well I think. Can’t pin point it or have any clue of where to start debugging.

I’m having the same issue. Everything works fine in Chrome but in Firefox:

The connection to ws://localhost:3000/sockjs-node/698/osuont4q/websocket was interrupted while the page was loading. websocket.js:7

Clean create-react-app works fine. ~Could there be something wrong in the upgrade process?~

Update: I’m using Found for routing. In my app I do a redirect from “/”. When I remove this redirect the dev server does not disconnect. But only if I navigate to “/”. Any other route still has the same error.