New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disconnected and looping in latest chrome #851

Open
rmanuel200 opened this Issue Mar 17, 2017 · 76 comments

Comments

@rmanuel200
Copy link

rmanuel200 commented Mar 17, 2017

"webpack-dev-server": "2.4.1",

Using these configurations:
devServer: {
historyApiFallback: true,
stats: 'minimal',
https: true,


module.exports = webpackMerge(commonConfig, {
devtool: 'cheap-module-eval-source-map',
//devtool: 'inline-source-map', //fix for IE sourcemaps 404??

Browser console.error:
client?fc09:45 [WDS] Disconnected!

Bug:
[WDS] Disconnected! happens multiple times when historyApiFallback = true
and host is not set.

This will happen about 5 times or more when the ng2 spa is refreshed either through browser or code edit in latest chrome. The server starts fine.

I'm on windows 10 pro v1607 build 14393.953

@rmanuel200

This comment has been minimized.

Copy link

rmanuel200 commented Mar 17, 2017

Actually the fix may have been to add a host:

host:"10.0.....",

but https://localhost:3000 will spin a lot after [WDS] Disconnected!. This problem seems to be somewhat project specific but I can't narrow down what it is outside of webpack-dev-server 2 using inline. For instance I removed proxy:{..., vpn, route guards etc. Setting wds option inline:false also fixes the problem but we want the page refreshes on code change.

@rmanuel200

This comment has been minimized.

Copy link

rmanuel200 commented Mar 19, 2017

wds

@SpaceK33z

This comment has been minimized.

Copy link
Member

SpaceK33z commented Mar 19, 2017

Does updating to 2.4.2 fix your issue? If not this might be a dupe of #848.

@rmanuel200

This comment has been minimized.

Copy link

rmanuel200 commented Mar 19, 2017

Upgrading 2.4.2 didn't fix it. I don't have hot module enabled but it may be the same problem, it seems similar. I ran one of angular's seed projects and it worked fine but the project is simplistic. Not sure why binding to a specific host does the trick. BTW my chrome was updated by IT remotely and I just upgraded to latest webpack and started using localhost so there are many changes occuring at once.

@joewood

This comment has been minimized.

Copy link

joewood commented Mar 20, 2017

I'm seeing this also. Just since the latest Chrome. Spins a few times "recompiling" and eventually settles down.

@rmanuel200

This comment has been minimized.

Copy link

rmanuel200 commented Mar 20, 2017

I made a project skeleton that demos the issue. https://github.com/rmanuel200/testwds

@cwharris

This comment has been minimized.

Copy link

cwharris commented May 4, 2017

I'm having this issue as well on webpack-dev-server@2.4.2. The webpack-dev-server client code fails to establish a websocket connection or the websocket is disconnected unexpectedly. Refresh ensues, whole processes starts over and repeats indefinitely. The issue only seems to occur with https enabled. Setting --host localhost per #592 did not resolve the issue.

@joewood

This comment has been minimized.

Copy link

joewood commented May 5, 2017

I think I resolved this because I was using - - watch on the command line, but also using a watch plug-in. I dropped the command argument.

@stevexy

This comment has been minimized.

Copy link

stevexy commented Jun 2, 2017

the same on Chrome 58.0.3029.110 (64-bit)。
webpack-dev-server version 2.4.5。
windows 7。

@langshu

This comment has been minimized.

Copy link

langshu commented Jun 6, 2017

Have the same issue here on Chrome 59.0.3071.86 (32-bit)
webpack-dev-server is the latest version - 2.4.5
OS - Win 7

@laizimo

This comment has been minimized.

Copy link

laizimo commented Jul 19, 2017

have the same issue here on Chrome 59.0.3071.86 (32-bit)
webpack-dev-server is the latest version - 2.5.1
OS - win 10

@Sayan751

This comment has been minimized.

Copy link

Sayan751 commented Jul 20, 2017

Have the same issue here on Chrome 59.0.3071.115 (64-bit)
webpack-dev-server version - 2.5.1
webpack version - 2.7.0
OS - Win 10

@soiaz

This comment has been minimized.

Copy link

soiaz commented Jul 20, 2017

Any updates on the issue @Sayan751 posted? Facing the same issue for the same configurations

@izziewong

This comment has been minimized.

Copy link

izziewong commented Jul 22, 2017

Having same issue as well, any updates?

chrome version is: 59.0.3071.115 (Official Build) (64-bit)
webpack version is: 2.6.1
webpack-dev-server version is: 2.4.5
OS is: macOS

@ywzhaiqi

This comment has been minimized.

Copy link

ywzhaiqi commented Aug 3, 2017

[WDS] Disconnected all the same In Chrome 59, Chrome 58, Firefox 54, webpack no compile.

2017-08-03_205635

webpack: 3.4.1
webpack-dev-server: 2.6.1

@shellscape shellscape added the question label Aug 9, 2017

@shellscape

This comment has been minimized.

Copy link
Contributor

shellscape commented Aug 9, 2017

If anyone can post a link to a simple repo using current dependencies/versions, with vanilla js and without using a framework, that consistently reproduces these symptoms, we'll be happy to take a look and attempt triage. At present none of our tests or examples reproduce this behavior.

We're going through issues to try and get the number of them under control so we can more effectively help folks. Closing this one due to age and lack of ability to reproduce, but the discussion is still open. If someone can provide that sample repo, we'd be happy to reopen.

@shellscape shellscape closed this Aug 9, 2017

@lirongfei123

This comment has been minimized.

Copy link

lirongfei123 commented Aug 22, 2017

just add this code to your hosts file, everything will be ok
127.0.0.1 localhost

@madaz

This comment has been minimized.

Copy link

madaz commented Sep 5, 2017

having same problems in Chrome 60.0.3112.113 64bit/Windows10

webpack-dev-server --open --inline --hot --content-base dist/ --config ./config/webpack.config.js --env.dev --env.serve

    "webpack": "^3.5.5",
    "webpack-dev-server": "^2.7.1"

webpack.config.js

      devServer: {
        headers: {
          'Access-Control-Allow-Origin': '*',
        },
      },

However it works in Firefox

@Reverbe

This comment has been minimized.

Copy link

Reverbe commented Sep 15, 2017

I also have this issue in Chrome Version 61.0.3163.91 (Official Build) (64-bit) (Win 10).

webpack 3.5.6
webpack-dev-server 2.7.1

@madaz

This comment has been minimized.

Copy link

madaz commented Sep 15, 2017

@lukace

This comment has been minimized.

Copy link

lukace commented Sep 25, 2017

We resolved this on Chrome/Win10/IIS/https by removing the script tag from the page, and instead use the inline:true flag in the webpackdevserver config. Your mileage may vary.

@dennisoelkers

This comment has been minimized.

Copy link

dennisoelkers commented Sep 26, 2017

Which script tag?

@lukace

This comment has been minimized.

Copy link

lukace commented Sep 26, 2017

WORKAROUND

"webpack-dev-server": "^2.8.2"

Specifically for the infinite refresh issue ([WDS] Disconnected) - I believe the issue is this (after deeper review):

the request for a websocket can timeout (transport). webpack-dev-server/client/socket.js sock.onclose eventhandler calls for a reload if this was the "first" connection attempt (retries == 0), when I think we just want to reconnect.

for a temproary fix, I manually changed these blocks in the webpack-dev-server/client/socket.js code:

  sock.onclose = function onclose({ code }) { //catch the code from the event
    //bypass the abort if the code is the transporttimeout
    //likely should just be: retries > 10, but didn't verify and didn't review cases for retries ===0
    if(code !== 1006 && retries === 0) { handlers.close(); };  

    if(code === 1006) {
      timedout = true; //defined private @filelevel
    }
    // Try to reconnect.
    sock = null;

    // After 10 retries stop trying, to prevent logspam.
    if (retries <= 10) {
      // Exponentially increase timeout to reconnect.
      // Respectfully copied from the package `got`.
      // eslint-disable-next-line no-mixed-operators, no-restricted-properties
      const retryInMs = 1000 * Math.pow(2, retries) + Math.random() * 100;
      retries += 1;

      setTimeout(function cb() {
        socket(url, handlers);
      }, retryInMs);
    }
  };

  sock.onmessage = function onmessage(e) {
    // This assumes that all data sent via the websocket is JSON.

    const msg = JSON.parse(e.data);

    //special handling for this case, as it triggers a reload. 
    if(timedout && msg.type == 'ok') {
      timedout = false;
      handlers['ok'](true);
    }
    else if (handlers[msg.type]) { handlers[msg.type](msg.data); }

  };

and this in webpack-dev-server/client/index.js

ok: function msgOk(to) {
    sendMsg('Ok');
    if (useWarningOverlay || useErrorOverlay) overlay.clear();
    if (to || initial) return initial = false; // eslint-disable-line no-return-assign
    reloadApp();
  },

These changes fix my particular issue

@dennisoelkers

This comment has been minimized.

Copy link

dennisoelkers commented Sep 27, 2017

Your snippet is missing the definition of timedout, probably happening in the same scope as sock?

@lukace

This comment has been minimized.

Copy link

lukace commented Sep 27, 2017

You got it (outside of the function "socket")

@jonaskello

This comment has been minimized.

Copy link

jonaskello commented Nov 30, 2017

@shellscape Here is a minimal repro of this issue: https://github.com/jonaskello/wds-disconnect-loop-repro

@michael-ciniawsky michael-ciniawsky added this to the 4.0.0 milestone Aug 23, 2018

@michael-ciniawsky michael-ciniawsky changed the title [WDS] Disconnected! loop in latest chrome [WSS (SockJS)] Disconnected and loop in latest chrome Aug 23, 2018

@michael-ciniawsky michael-ciniawsky changed the title [WSS (SockJS)] Disconnected and loop in latest chrome Disconnected and looping in latest chrome Aug 23, 2018

@Rouche

This comment has been minimized.

Copy link

Rouche commented Aug 25, 2018

Had this problem for a while and solved it in a odd way.

Dev server starts with 2 adress:

  App running at:
  - Local:   https://localhost:8085/
  - Network: https://192.168.0.151:8085/

I was using https://localhost:8085/ in browser, but the sock was connecting with Network.

Request URL: https://192.168.0.151:8085/sockjs-node/info?t=1535198535563
[WDS] Disconnected!

When i used https://192.168.0.151:8085 in browser instead of localhost, chrome shown the window to accept certificate and proceed.
Now everything is ok, on both localhost, and ip.

No need for flag. It was not working when i tryed.
I never bothered to try Network adress.. /bonk. This was too simple.

@michael-ciniawsky michael-ciniawsky added this to Refactor in Dashboard Aug 25, 2018

@blackshadev

This comment has been minimized.

Copy link

blackshadev commented Aug 27, 2018

@Rouche This wasn't the case for me. My sockjs is connecting to locahost. Moreover my webpack-dev-server doesn't even listen on an ipaddress besides localhost.

Even if it would, that work-around wouldn't work for me, because I use an external service which has a CORS header for a local development setup, but this doesn't work with the IP address because multiple devs (with other IPs connect to it) and a CORD wildcard doesn't work because Chrome just drops CORS wildcards with SSL .

@ckarcz

This comment has been minimized.

Copy link

ckarcz commented Sep 12, 2018

using 127.0.0.1 instead of localhost fixed this for me 🤷‍♂️

@dvakatsiienko

This comment has been minimized.

Copy link

dvakatsiienko commented Sep 12, 2018

I have fixed this issue by switching to webpack-serve instead of webpack-dev-server. pretty neat package btw

@simardo

This comment has been minimized.

Copy link

simardo commented Sep 19, 2018

@ckarcz, running webpack-dev-server with --https --host 127.0.0.1 fixed the problem for me as well.
I can even access my site with https://localhost without problems.

//cc: @Rouche

@Rouche

This comment has been minimized.

Copy link

Rouche commented Sep 19, 2018

Today after chrome update bang!
Self signed certificate altName is now mendatory.
No choice to use host.

With vue-cli3 config:

module.exports = {
...
    devServer: {
        open: process.platform === 'darwin',
        host: 'localhost',
        port: 8444,
        https: true,
        hotOnly: false,
    },
}

Yo @simardo 👍

@WellspringCS

This comment has been minimized.

Copy link

WellspringCS commented Oct 4, 2018

I tried many of the above suggestions, and I could very much have gotten some things wrong, but here's what worked for me. (I call this "guns a'blazin" mode, where you try anything, out of desperation....)

(And note that the following efforts are not listed chronologically. I'm not sure I was sane during the last two days since this issue benighted my life.)

I started on Angular 6, ended up Angular 7.0.0-rc1 ---> WDS disconnect still there.
I started on webpack-dev-server I.don't.know and ended up on 3.1.5 ---> WDS disconnect still there.
I started on sockjs-client I.don't.know and ended up on 1.1.5 ---> WDS disconnect still there.
I tried all the above IP solutions. ---> WDS disconnect still there.

And by there, I mean endless looping. Quoth the raven: Disconnected!

Finally out of sheer desperation, the country bunkin tried brain surgery using the manual. I have NO idea what I did, but I did exactly what @lukace said he/she did, modifying socket.js and index.js.

And....

It worked.

What I would like to know is whether the code @lukace modified should be considered a bug to be fixed. For my project, EVERYTHING works now, and it didn't before. All my project was trying to do was redirect to an OAuth2 server to get a security token, and all I was getting was endless looping.

All that to say, my project was dead in the water, using all the latest releases. I don't think I had a bug, but this fix was required for my Angular project to work with OAuth2 security.

For the sake of the next soul, I log these reflections, but am wondering if an issue should be opened somewhere. Is this a sockjs-client bug? webpack-dev-server bug? @lukace I'm sure what you said was enough to go on, but I'm not a brain surgeon, so I can't discern whether your fix is a global good for all or just a good workaround that has its downsides for other users. As for me I think it's REQUIRED, but hey, I might be biased.

I end with these words of gratitude: @lukace you saved my bacon. I'll name my next dog after you. If my wife ever lets me buy one.

@mayacoda

This comment has been minimized.

Copy link

mayacoda commented Nov 30, 2018

We have a Vue app using webpack-dev-server and encountered the same issue (using version 2.11.3, but it persisted with newer versions as well). After a lot of digging, turns out our problem was multiple websocket connections, specifically SockJS instances, spawning on application load and causing each other to time out and disconnect. The SockJS documentation even points out this problem:

An important SockJS limitation is the fact that you're not allowed to open more than one SockJS connection to a single domain at a time. This limitation is caused by an in-browser limit of outgoing connections - usually browsers don't allow opening more than two outgoing connections to a single domain. A single SockJS session requires those two connections - one for downloading data, the other for sending messages. Opening a second SockJS session at the same time would most likely block, and can result in both sessions timing out.

The cause as a badly configured html-webpack-plugin which created dummy JS files instead of loading CSS. Still not entirely sure why/how this happened, though. The way I caught it was by adding a console.trace to webpack-dev-server/client/socket.js right under the line sock = new SockJS(url); and then tracing what files created new SockJS instances during runtime.

@evilebottnawi

This comment has been minimized.

Copy link
Member

evilebottnawi commented Dec 6, 2018

Somebody can create minimum reproducible test repo?

@silvenon

This comment has been minimized.

Copy link

silvenon commented Dec 21, 2018

Not sure when this started happening, but it seems to happen in every browser. Here's a repro.

@c80609a

This comment has been minimized.

Copy link

c80609a commented Dec 22, 2018

Works for me, webpack.confg.js:

module.exports = {
  devServer: {
    headers:          { 'Access-Control-Allow-Origin': '*' },
    https:            false,
    disableHostCheck: true
  },
  [...rest]
}
@silvenon

This comment has been minimized.

Copy link

silvenon commented Dec 22, 2018

Works for me when I downgrade to 3.1.10, without any additional options. #1604 (comment)

@panzelva

This comment has been minimized.

Copy link

panzelva commented Dec 23, 2018

@c80609a's solution worked for me - actually simply adding disableHostCheck: true to devServer options worked.

@monteiz

This comment has been minimized.

Copy link

monteiz commented Jan 3, 2019

In our case the issue was due to a mismatch between the host name that webpack-dev-server was using to serve the asset, and the host name the application was running from.

Specifically, our local application was running from https://dev.resumize.me, but webpack-dev-server was serving the asset from 127.0.0.1.

You can control the host name used by webpack-dev-server with the option --host. So in our case, we had to launch it with:

webpack-dev-server.js --host dev.resumize.me --https

Hope this helps.

@laryssamagalhaes

This comment has been minimized.

Copy link

laryssamagalhaes commented Jan 3, 2019

On chrome works, but I've the same problem on the firefox (64.0) 😢

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment