Tab limit per browser?

[Sawtaytoes]

Hi! I'm using webpack-hot-middleware v2.21.2 and seem to be having a problem with the number of tabs I can have open per browser per Webpack instance. I recently moved to webpack-hot-middleware and don't remember having this issue with webpack-dev-server.

Do you know if it's a set limitation in webpack-hot-middleware? There's a fixed number of 6 tabs I seem to be able to open at the moment. Anymore, and I get an infinite loader.

If I open tab 7, it will be stuck loading forever. As soon as I close any tab 1-6, it immediately load the page.

[joshwiens]

I remembered something old relating to that particular number & went digging.

https://stackoverflow.com/questions/23679968/chrome-hangs-after-certain-amount-of-data-transfered-waiting-for-available-soc

I am in no way an expert on hot-middleware, but I have run into something similar with socket.io when connections weren't upgraded ( XHR poll vs. Socket connection )

[Sawtaytoes]

Looks like you found it!

webpack-dev-server definitely uses WebSockets. Does it not have the restriction because it's WebSockets instead of Server-Side events?

And is it possible webpack-hot-middleware could switch to using WebSockets if that fixes the issue?

[glenjamin]

The default browser limits vary depending on the transport used.

Can I ask why you need to have so many active tabs open during development?

There are some possible strategies available by making the client either poll for changes, drop connections when not the active tab, or potentially even share the same instance across the distinct js windows.

The simplest thing to do is probably to up your limits locally.

[glenjamin]

Also, webpack-hot-middleware is designed to seamlessly combine with an existing server. Because websocket events are global on an express server instance, it is not possible to use web sockets and keep this goal intact.

This question has come up a few times before, i’ll look into creating an FAQ section of the docs at some point

[Sawtaytoes]

Thanks for responding!

I have an iframe managing authentication in a bunch of micro apps. If I want to open them all for testing, I need to use more than 6 tabs because the auth service runs in an iframe in every app. There are 16 apps so far with more in the works. Various apps are dependent on each other for different pieces of functionality so I might have quite a few open when testing.

The iframe was my way around localStorage being same-origin-restricted for subdomains without lowering the same-origin policy.

More info if you're curious why I'm dependent on an iframe:
https://community.auth0.com/t/synchronizing-sessions-across-multiple-web-apps/10455/5?u=sawtaytoes

When doing load testing locally, I also open a bunch of tabs on purpose to see how it would affect a user's machine. I'm working under the assumption users are negligent about closing tabs. I can't test that if I'm being artificially limited.

[glenjamin]

Ok, that makes sense - it is relatively unusual to need to have lots of tabs open in the same browser and an SSE connection open for each one - except for when locally testing exactly the sort of thing you are describing.

The following links suggest some ways to increase this limit:
https://stackoverflow.com/questions/16852690/sseeventsource-why-no-more-than-6-connections
https://stackoverflow.com/questions/18584525/server-sent-events-and-browser-limits

[Sawtaytoes]

Is there a major performance impact to using SSE rather than WebSockets? I understand it's not a simple change to move to WebSockets, but I'm wondering now if maybe webpack-dev-server (or something else) is better suited to my needs. webpack-dev-server is using WebSockets instead of SSE, and I run everything off Express already so having webpack-hot-middleware was more preferred than proxying webpack-dev-server to Express; running 2 webservers instead of 1.

Also, I'd rather not have to ensure all developers and every machine used for development of any Webpack applications raise the SSE connection limit. This not only affects work machines, but laptops, desktop computers, anything else I have where I'm doing Webpack development including other developers.

I'm conflicted because I prefer webpack-hot-middleware, but the synchronization model appears to be limiting.

[glenjamin]

The SSE approach is a bit limiting, but most users don’t run into these limits.

There is some discussion from the early days in #121

The goal of this module has always been primarily to allow adding to an existing express server

Express handles all requests, and passes them to the routing layer. This allows the middleware to intercept relevant requests and pass the rest on through to the real application.
Unfortunately, express doesn’t handle websockets at all, so there is no standard way to have this middleware handle some websocket requests, but not others.

The only way to safely handle websockets in the same process is if the original server doesn’t do any websocket stuff, or has a websocket routing library we could hook into.

The possible approaches I can see for you if you want to keep a single process are:

1. write your own middleware/client, this could be a fork of this lib, or just some code embedded into your project. You wouldn’t need to handle the wide range of scenarios we do, so would be free to use a websocket transport and adapt things to suit your setup.

There’s actually surprisingly little code required to do this.

2. require anyone running your Dev environment to increase the number of connections if they want hot reloading to work as discussed above

3. I’d be open to accepting a PR which adds options to force this middleware to run in a polling mode, which would sidestep your active connections problem and still be compatible with the routing / middleware approach.

[noe132]

@Sawtaytoes hi, maybe try webpack-hot-client? It uses websocket to communicate between client and server, and you can attach it to an existed server like express or koa.

@glenjamin I think maybe adding docs in Troubleshooting section to explain that the browser same domain connection limit thing would be nice to those people wen't into this problem, at least for me it took me a long time on digging this before realizing that it was browser limiting my connections rather than the server not responding.

[minimit]

I've problems too with many iframes (the iframes loading hungs up when more than 3-4)

I've found a fix in init() in client.js, if I add clearInterval(timer); and source.close(); I can have as many iframe as I want, also on multiple browser tabs the websites update. The only Thing is that the console log doesn't print "[HMR] connected" anymore.

  function init() {
    source = new window.EventSource(options.path);
    clearInterval(timer);
    source.close();
    source.onopen = handleOnline;
    source.onerror = handleDisconnect;
    source.onmessage = handleMessage;
  }

I'd do a pr but I don't know if it breaks something I'm new to webpack and this plugin.

[minimit]

Inside iframes you also get more connection because in getEventSourceWrapper() window it the iframe window, but with clearInterval(timer); and source.close(); you can have more than 5 connections I don't know why (also more than 5 tabs)