👍 I just ran into this as well, but I'm getting it on the first request.

screenshot: http://take.ms/H6typ

Interesting, closing and re-opening the chrome window fixed the problem.

Hmm, I'm currently using Chrome Canary v45.0.2416.0 on OSX and I haven't run into this problem.

Unfortunately closing and reopening chrome doesnt fix it for me. I have tried it across machines and also with Chrome Canary (not got the version number to hand).

I'm having the same issue. Google Chrome on OSX. When I save an HTML file multiple times, I end up getting a bunch of hanging requests on the third or fourth reload. Closing and opening a new tab generally fixes the problem.

EDIT: Just had to empty my cache and everything started loading properly

Ive tried clearing the cache and history. Still get the issue, even Canary.

I had this issue happening all the time on my Aurelia.io app. I updated package.json to use
"browser-sync": "2.7.11",
instead of .13 and the issue is no longer occurring.

+1

A small repository that can reproduce the error is very welcome.

i have same issue with aurelia app, going back to older version as @jadrake75 suggested did not work, only clearing chrome cache worked, but this is so annoying!!!

it also happen with firefox

i am on windows 8 64x machine, nothing changed or installed recently

Interesting... that setting is enabled for me which might explain why going
back to an older version didn't assist you. Are you seeing it with that
open enabled (disable cache) with the latest?

On Sun, Jul 12, 2015 at 6:14 PM, devmondo notifications@github.com wrote:

i have same issue with aurelia app, going back to older version as
@jadrake75 https://github.com/jadrake75 suggested did not work, what
worked for me is enabling disable cache when developers tools windows is
opened in chrome

—
Reply to this email directly or view it on GitHub
#650 (comment)
.

@jadrake75 issue still exists wither i use latest or your version even when the disable cache option enabled

@jadrake75 are you using any socket.io or localstorage in your app code? i have noticed that once i make some socket.io events the problem starts to happen

ok it is local storage!, i disabled localstorage code in my app and problem does not exist , i will test more

ok, to help anyone out, check your code and make sure no library or code is having memory leaks, it just blows up chrome, i removed the issue, it was caused by npm jsondiffpatch and now browser-sync works perfectly :)

I was having this issue using gulp-connect and then switched to BrowserSync to see if if I could get it to stop happening, just to find out that it still happens with BrowserSync. I had the same setup that @lynden had, and the issue persisted. I did some checks and found out it's a connect issue itself, so we did a few more changes and found doing what this says, fixed the issue. https://github.com/BrowserSync/recipes/tree/master/recipes/gulp.jade

So, I was running on 2.7.3, upgraded to 2.7.13 and the problem has gone for me.

I am having the same problem. It occurs on Chrome for both linux(ubuntu) and mac. Never happens on firefox.

I don't think it is caused by a memory leak. Solving a leak did not help at all. I am using localstorage as commented before but I cannot disable it.

Also as the app grew bigger the problem became more frequent.

I've been fighting this for awhile, I find it happens if I save a file twice quickly (I.e., before my "scripts" task finishes). Will investigate and report back...

Same issue here with the latest Chrome and browsersync on Mac OS X. Have to kill Chrome multiple times per day since it's just hangs on a page firing off multiple requests. I can't even close the tab. I have to force kill the browser.

browser-sync@2.16.0 
node@6.4.0
Mac OS X@10.11.6

I have the same issue, getting long pending requests, which never end.

My setup includes browsersync + webpack-dev-middleware + webpack-hot-middleware, no gulp overhead.
All HMR stuff for js, css, svg is delegated to webpack through browsersync's middleware option, html and others are watched by browsersync.

Versions:
node@5.10.1
npm@3.8.3
browser-sync@2.16.0
webpack@1.13.2
webpack-dev-middleware@1.6.1
webpack-hot-middleware@2.12.2

Same in Chrome@53.0.2785.116 (64-bit) and Chrome Canary@55.0.2872.0 canary (64-bit)
If I test it with firefox, it never happenend so far...

@shakyShane
Do you have any time to look into this issue?
I tested my browsersync setup locally with firefox, Safari, and chrome (all latest versions) and this pending appears only on chrome.
Unfortunately this issue is already more than a year old, would appreciated a lot if we could get a solution:)

Not sure if this helps, but I often experience Chrome/Mac OS X just "getting stuck" viewing regular web pages. The way to bring it back to life is to go to chrome://net-internals config page and click on "Close idle sockets" and "Flush socket pools" button (see image below). Then it works fine for another few days. Then I have to repeat the same process again. Pretty annoying.

@AndyOGo the problem is that no-one has provided a sample app that can reliably re-produce this.

without such a project it's extremely difficult/impossible to even begin to debug this, as much as I would love to provide a solution

@shakyShane
Thanks for your kind and quick answer. I understand, I'm in the same situation. I double and tripple checked the docs. enabled all log levels, but no hint of what is wrong.

So far I consider three things:

1. It's just a chrome bug which got not fixed so far
2. Maybe a dependency of browsersync like sockets.io
3. I have a special setup where I use Iframes, which loads content from the same browser-sync instance

But those are just assumptions.
Unfortunately I have allot to do at the moment, but I would like to provide this reduced test case (if I can).

And thanks to @demisx
That is indeed interesting to know.

Totally understand how this thing would be so difficult to troubleshoot. I have hard time figuring out the pattern myself, because it happens randomly and when it happens Chrome just hangs sending off one request after another. I can't even get to web developer tools or any other menu item. The only way to get out of it is to kill Chrome, restart browser-sync and start over again. If you guys have any tips on how to capture the info helpful to @shakyShane debug, please share it. If I manage to capture any output when it enters the eternal request loop again, I will make sure to post it as this is becoming a nuisance in dev (happened 3 times in the past 2 hours).

Here are the requests that are flooding my Web Developer Tools Net panel when Chrome enters internal loop:

@shakyShane @demisx
So, I just had some time to investigate the network panel.
In fact all calls to http://localhost:3000/browser-sync/socket.io/?EIO=3&transport=polling&t=[hash] which end up being stalled are called from iframes - both the parent window and the iframe's content are using the bs client and are served from the same bs instance.

My assumption is that there could be a pool with a maximum of concurrent connections (maybe just in chrome).

Guys, any progress on this. Using the latest browser-sync 2.18.6 and it's unusable. A couple of clicks and the entire Chrome just freezes.

I am having the same issue.
For me - I added an XHR request and once I call "document.write(some parsed JSON)" it was creating me that panding request.
@shakyShane I've created a public repo for you to reproduce the issue: https://github.com/alexcracea/bs-pending-request - note: Just in case you don't have gulp globally i added support for you to run "npm run gulp" when you're inside ".npm" folder.

As you can see, the request from url ws://localhost:3002/browser-sync/socket.io/?EIO=3&transport=websocket&sid=TR1X04-6mgbAHe7IAAAH is not being processed. In my case, the browser "loading" icon was appearing only while i call "document.write();"

Thanks @alexcracea !

I'm still experiencing this problem...

Me too. Forced to use Firefox for now.

chrome just logged me about an cross-site script Parser-blocking.
Strangly it just start handging there...

A Parser-blocking, cross site (i.e. different eTLD+1) script, https://www.google.com/uds/api/visualization/1.1/cc5d8333ad9d2dca8ea31ac15ed4e2df/webfontloader,format+en,default+en,ui+en,corechart+en.I.js, is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message.See https://www.chromestatus.com/feature/5718547946799104 for more details.
google.loader.f @ jsapi?autoload={'modules':[{'name':'visualization','version':'1.1','packages':['corechart']}]}:22
(anonymous) @ jsapi?autoload={'modules':[{'name':'visualization','version':'1.1','packages':['corechart']}]}:54

In my case, it is caused by a infinity loop in my code😂

I am also facing same issue. I am using 2.24.6 with gulp.
Please help

Having the same issue on 2.24.6 with gulp. I have browsersync in proxy mode to a backend running on localhost:5000 and noticed a few things:

• Other browsers (firefox) work just fine
• Same Chrome in anonymous mode works just fine
• Normal, non-anonymous, chrome window hangs
• Hitting the actual backend being proxied to in a separate tab, makes the frozen tab unfreeze and process the request

A little update: Flushing socket pools and closing idle sockets from chrome://net-internals, as suggested by @demisx does resolve the issue when done while the window is hanging.

If i set up domain of socket like this:

socket: {
    domain: 'localhoooooooost:8080'
}

Reloading the page works fine.
But then i see errors in my console.