Browser-sync: Unexpected Page Reload after Pausing in Debugger

[janmattfeld]

Steps to reproduce/test case

1. Add a breakpoint in Chrome debugger
2. Wait until execution stops and hold on for a few seconds
3. Continue via F8 to or click the play button
4. Unexpectedly, the entire page is refreshed and the code runs from beginning

Please specify which version of Browsersync, node and npm you're running

• Browsersync [2.24.6]
• Node [v10.8.0]
• Npm [6.2.0]

Affected platforms

• [X] Windows 10 x64

Browsersync use-case

• [ ] API
• [X] Gulp
• [ ] Grunt
• [ ] CLI

for all other use-cases, (gulp, grunt etc), please show us exactly how you're using Browsersync

browserSync.init({
  server: ["./webapp/", "./webapp/test", "./"],
  index: "index.html",
  notify: false
});

References

There are already two Stack Overflow posts:

• https://stackoverflow.com/questions/51589521/browser-refresh-after-breakpoint
• https://stackoverflow.com/questions/51762881/browser-getting-refreshed-after-resuming-debugger

And a message in Slack:

• https://browsersync.slack.com/archives/C08KRLMNU/p1534261773000100

[guifes]

This is extremely annoying. Can anyone point to the most up-to-date version that does not have this problem?

[singlow]

I have this problem as well. I have had some success by increasing the client heartbeat timeout:

browserSync.init({
...
    socket: {
        clients: { heartbeatTimeout: 60000 } 
    }
...
});

[shakyShane]

@janmattfeld I'm trying to recreate this, without success - is there any way you could put together a minimal example that shows the bug?

[gama410]

I already commented on this issue which seems to be related. After trying several releases, I found out the problem started with 2.24.5.

I "fixed" it the same way @singlow described (although a proper fix would be very appreciated ;) )

[chiplay]

We are having the same issue, and heartbeatTimeout didn't seem to do the trick for us. Downgrading to 2.23.7 prevents the reload.

[aj-dev]

Same issue here. Increasing heartbeatTimeout didn't help.

[gama410]

Actually, I noticed that increasing heartbeatTimeout didn't really fix the problem either. If I pause on a breakpoint for a few seconds, browsersync seems to reload the page anyway, only it will wait until after heartbeattimeout expires to perform the reload...

[janmattfeld]

@shakyShane I uploaded the most minimal example I could imagine and attached it to the first post.

npm install
gulp

Then set a breakpoint in the timeout within app.js, wait 20 seconds before continuing and you will (hopefully) experience the same unexpected page reload as we do.

[chiplay]

Small update - did some experimentation with proxy.target and socket.domain options and found a combo that seems to prevent the reload from happening. I still get a console error Invalid Frame Header after 60 seconds (the initial websocket connection seems to fail...) but browser-sync continues working just fine in spite of the error.

Not sure how helpful that is, but I figured I'd comment just incase!

EDIT: Still reloads when paused on breakpoints... so probably not a real solution/lead.

[axten]

same problem here, downgrade works

[pioug]

I have no issue with [email protected], so I digged a bit:

1. I think the issue started here with the update of [email protected] https://github.com/BrowserSync/browser-sync/commit/dd70eba92b61f99bf9d67a6fcd825ee1d6e91964
2. engine.io has been updated in that version of socket.io https://github.com/socketio/socket.io/commit/b1941d5dfe3d2530bb0f0391088d3c8765ae9695
3. Default value for timeout was decreased in [email protected] https://github.com/socketio/engine.io/commit/65b1ad1b8a95fb0547ee3f286c1b7da299c7735a

Setting heartbeatTimeout: 60000 works also for me 👍

[mpelekh]

Same problem.

I have this problem as well. I have had some success by increasing the client heartbeat timeout:

browserSync.init({
...
    socket: {
        clients: { heartbeatTimeout: 60000 } 
    }
...
});

The increasing of heartbeatTimeout doesn't help in all cases. It just reduces the possibility of the page refreshing.

It works in cases when heartbeatTimeout is not ended. What I mean by that is the following.

Imagine that you have set the timeout to 60000 ms. And just 2 seconds have passed from the beginning of the timeout cycle. And then you stop the application by breakpoint for 10 seconds. 2 + 10 = 12 seconds, so the application will resume work as needed without the page refreshing.

But in case when 58 seconds have passed from the beginning of timeout cycle, for instance, and then the application is stopped by the breakpoint for 10 seconds. 58 + 10 = 68 seconds. It more then heartbeat timeout, so the application will be refreshed by browsersync after resuming.

[chiplay]

I can confirm @mpelekh's report as well. Increasing the heartbeatTimeout doesn't prevent the reload, it just delays it. It my case, if I set a breakpoint, hit it, and then _immediately_ resume, then wait until the 60 seconds is up, it will refresh the browser.

[fheidrich]

Please help, this is very annoying.

[axten]

as mentioned before, a downgrade to 2.23.7 works

[chiplay]

FWIW version 2.23.7 has a good number of dependencies that are flagged by npm 6 as security issues. Ideally we can find a fix to prevent the full BrowserReload event when the socket handshake closes/reopens

[maynir]

This is so annoying, it happens to me too.
The change in heartbeatTimeout helped for a bit longer waiting time, but not too much.
I am using version 2.24.6, should I downgrade browser sync?

[cenfun]

Same issue here. I just roll back my browser-sync to version 2.24.1, it works. hope it could helps you fixing it in latest version.

[chiplay]

Doing some more sleuthing on this issue, here is what I'm finding:

The reload starts when one of the polling request returns a 400 with this response: {"code":1,"message":"Session ID unknown"}

When the new socket is created, this gets called with an index > 0: https://github.com/BrowserSync/browser-sync/blob/master/client/lib/messages/Connection.ts#L24 which triggers the refresh. I removed that last line locally and it prevents the reload and continues to work as expected with the new connection. Going to submit a PR with the change.

[chiplay]

That last comment was premature, removing that line from Connection.ts causes other issues.

[scottschafer]

I also "fixed" the problem by downgrading. This is a severe issue.

[shakyShane]

Hi all, this is being worked on as a priority - thanks for your patience :)

[shakyShane]

Ok I have a fix in place, could anyone in this thread give the alpha release a test-drive?

npm i [email protected]

[shakyShane]

Breakdown of cause + fix:

engine.io (that socket.io uses under the hood) updated some default values - this meant that whilst the debugger was paused inside applications, the connection dropped.

The moment the debugger stops, a new 'connection' event is received via socket.io (as it manages to re-connect imediately) and then some code in the Browsersync client would cause a full-page reload since this re-connection event was not the 'first' one - this was done to allow situtations where a computer is put to sleep, or anything else that could cause a drop in connection.

I'm no longer confident it was a good idea since this bug came around - and it's also not a good idea to increases timeouts etc.

The simple solution is to no-longer reload the page automatically following a re-connection :)

export function incomingConnection(
    xs: Observable<IBrowserSyncOptions>,
    inputs: Inputs
) {
    return xs.pipe(
        withLatestFrom(inputs.option$.pipe(pluck("logPrefix"))),
        mergeMap(([x, logPrefix], index) => {
-            if (index === 0) {
               return of<any>(
                    setOptions(x),
                    Log.overlayInfo(`${logPrefix}: connected`)
                );
-            }
-            return reloadBrowserSafe();
        })
    );
}

[Chandra01B]

Is this issue is resolved with 2.25.1 ?

[alexpmorris]

just had to add how happy I am as well that this one was nipped in the bud, it's been driving me bonkers as well! :D lol

[shakyShane]

@alexpmorris glad to hear it :)