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

Created on 26 Mar 2019  路  29Comments  路  Source: facebook/create-react-app

Hi,

When developing using create-react-app in Firefox 66.0.1, hot module reloading isn't working, and I get this error in console when using npm run start:

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

This doesn't happen in Chrome, and HMR works there as expected. I didn't have problems in the past with Firefox, I'm not sure if it's triggered by a Firefox update, or new versions of react-scripts. It may even be specific to my app.

I'm using react-scripts versions 2.1.8

Does anyone know what would cause this, and how I could get HMR working again? I'm not really sure where to look.

Thanks

bug needs investigation

Most helpful comment

Don't close it stale bot! 馃槆

All 29 comments

@andygock what version of create-react-app are you using?

@Jbonez87
I'm using version 2.1.8

@andygock I'm not able to reproduce this error using npm run start or yarn start. What version of npm are you using? I'm using this version:

npm -v
6.9.0

@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.

i started a new project yesterday, and i know it was working yesterday. react-scripts 2.1.8, yarn 1.12.3, node v8.15.1. i see firefox updated a few hours ago, so i'm going to blame firefox 66.0.2 for this one (had 66.0.1 yesterday)

@jayenashar it could be webpack-dev-server too. Note that devDependencies in its package.json:

"devDependencies": {
    "@babel/cli": "^7.2.3",
    "@babel/core": "^7.2.2",
    "@babel/preset-env": "^7.3.1",
    "babel-loader": "^8.0.5",
    "copy-webpack-plugin": "^5.0.0",
    "css-loader": "^2.1.0",
    "eslint": "^5.4.0",
    "eslint-config-prettier": "^4.0.0",
    "eslint-config-webpack": "^1.2.5",
    "eslint-plugin-import": "^2.9.0",
    "eslint-plugin-prettier": "^3.0.1",
    "execa": "^1.0.0",
    "file-loader": "^3.0.1",
    "html-loader": "^0.5.5",
    "html-webpack-plugin": "^3.0.6",
    "husky": "^1.3.1",
    "jest": "^24.3.1",
    "jquery": "^3.2.1",
    "less": "^3.7.1",
    "less-loader": "^4.1.0",
    "lint-staged": "^8.1.1",
    "marked": "^0.6.1",
    "nyc": "^13.3.0",
    "prettier": "^1.16.3",
    "puppeteer": "^1.12.2",
    "rimraf": "^2.6.2",
    "standard-version": "^5.0.0",
    "style-loader": "^0.23.1",
    "supertest": "^3.0.0",
    "url-loader": "^1.1.1",
    "webpack": "^4.29.0",
    "webpack-cli": "^3.2.1",
    "ws": "^6.0.0" // websockets included here
  },

@andygock I think this is an issue with ws and webpack-dev-server, not create-react-app itself. I would open a bug ticket on ws and on webpack-dev-server

i didn't update any node modules between yesterday and today. the only thing i can think of that has changed is firefox.

@jayenashar it doesn't look there were any javascript changes here in the latest version of Firefox: Firefox changelog

If you still think the issue is with Firefox, it might be more beneficial to create a bug ticket here: Bugzilla

I just did some experiments:

Firefox 60.6.1 ESR - works okay

Firefox 66.0.2 - websocket error

Clean PortableApps install, no add-ons or extensions.

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.

@andygock I know in the past create-react-app has had issues when using npm and npx (the one that comes to mind for me is "Cannot resolve module 'chalk'"). Just as a sanity check, could you try starting your app with yarn? What OS are you using? You can install yarn with homebrew if you don't have it already

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.

i'm not using any extra packages.

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

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.

https://github.com/socketio/socket.io/issues/2016#issuecomment-392241457
looks like some ip/hostname issues?

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

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.

Just checked - same issue for Firefox 66.0.3 (now using 65.0.2)
For 66.0.X works only after removing proxy option from package.json

Just checked - same issue for Firefox 66.0.3 (now using 65.0.2)
For 66.0.X works only after removing proxy option from package.json

@dmile looks consistent with other responses and analysis done by Firefox team. Now we only need to figure out which product is misbehaving. Good news is that it is not Firefox.

I have created one more issue in webpack-dev-server.

Connection aborted because webpack-dev-server trying to proxy sockjs request

1. When proxy enabled webpack-dev-server uses http-proxy-middleware

2. http-proxy-middleware checks every request with [shouldProxy](https://github.com/chimurai/http-proxy-middleware/blob/b13302c87a04bf7adc4c2547affaaeeb7ecb0c42/src/http-proxy-middleware.ts#L92) and result depends on proxy context

3. Default proxy context defined in react-dev-utils and [rely on accept header](https://github.com/facebook/create-react-app/blob/master/packages/react-dev-utils/WebpackDevServerUtils.js#L404)

4. The header is different for browsers

Firefox 65.0.2
Firefox 65.0.2
Firefox 66.0.3
Firefox 66.0.3

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?

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

Mine also worked after removing proxy option in package.json in my react app

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

Don't close it stale bot! 馃槆

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

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

Sorry for the very late reply here. I'd be happy for you to raise a PR to fix this. Keep in mind that @gaearon also has a PR in the works to improve HMR for React which may modify how some of this works.

@mrmckeb please take a look at #7444

Was this page helpful?
0 / 5 - 0 ratings