Browser-sync: Conflict when webpage also uses Socket.io

Created on 14 Feb 2014 · 14Comments · Source: BrowserSync/browser-sync

Browser-sync v0.5.7 works perfectly if I proxy the PHP server. But when using with my nodejs server from the command line (browser-sync --proxy "localhost:5000" --files "public/asset/css/*.css", where my NodeJS site runs under localhost:5000), the webpage looks as following:

browser-sync-nodejs

bug

Source

nghuuphuoc

All 14 comments

is your globally installed BrowserSync at version 0.5.7?

it looks like your node server is sending a gzipped response - even though BrowserSync sets a header that should stop that...

shakyShane on 14 Feb 2014

Yes, I installed BrowserSync with -g parameter.
My web app uses ExpressJS. I will check if it gzips the response or not

nghuuphuoc on 14 Feb 2014

I don't know why but the web app render properly now.
But after loading the page, then a few seconds later, it automatically redirect to a socket-io backend URL as following:

redirect

I uses socket.io in my NodeJS app:

<script type="text/javascript" src="/vendor/socket.io/socket.io.min.js"></script>
<script type="text/javascript">
$(document).ready(function() {
    // The following line might be the reason
    // When I comment it, the page does not redirect
    // Uncomment it, the page redirects to a socket.io URL as I mentioned above
    //io.connect().emit('userName', '....');
});

nghuuphuoc on 14 Feb 2014

BrowserSync has not yet been tested to work with web-sockets.

If you disable options.ghostMode.links then it will work for you until this gets fixed

ghostMode: {
    links: false
}

shakyShane on 14 Feb 2014

👍1

I've noticed this error, "redirect to a socket.io backend URL".

I suspected this has to do with the multiple socket.io clients interfering with one another. Having browser-sync use Socket.io rooms seems to fix this problem for my app, but the browser-sync proxy does not proxy websocket connections so my app fails nonetheless with browser-sync. I would like to help fix this problem.

Socket.io rooms: https://github.com/sfarthin/browser-sync/commit/c59578ff5548c2b72ec8365f4ab82dedc79394c3

sfarthin on 14 Feb 2014

I am able to get XHR long polling to work with Socket.IO 1.1.0 + BrowserSync 1.3.6 (via grunt-browser-sync), tho the aforementioned lack of WebSocket proxying by BrowserSync gives a WebSocket connection to 'ws://...' failed: Connection closed before receiving a handshake response . error when attempting to upgrade (error from Chrome).

A couple tricks helped me get there:

Set io.path to something other than the default /socket.io, which BrowserSync uses. I used /app/socket.io, serving my client from /app/socket.io/socket.io.js.
Use the new Socket.IO io.of() namespaces to keep multiple connections separate.
On the client, I use the default BrowserSync script injection, which is async at the top of the <body>. This usually results in the final window.io as the browser-sync client, but have seen the rare case where the BrowserSync client will load faster than the app Socket.IO client. In any case, I immediately grab my window.io and store it as a property on my app global object for when BrowserSync loads its version. Then I can always use app.io on the client and know I mean my Socket.IO connection, not BrowserSync's. I pray that BrowserSync is compatible with my client version if mine loads last, but that doesn't happen as often.

Anyway, thought some information would be helpful. In particular, being able to configure the Socket.IO path & namespace used by BrowserSync would be awesome, and help prevent a lot of these conflicts. Maybe also omitting the io client global in favor of a browserSync global with browserSync.io as the method for accessing it could keep things cleaner.

Proxying WebSockets would be really nice too.

vml-sdaniel on 10 Sep 2014

thanks @vml-sdaniel

I'm keen to resolve this issue & it sounds like you've worked out what's needed to fix - can I convince you to contribute? :)

shakyShane on 10 Sep 2014

Submitted some pull requests from my personal account.

simshanith on 11 Sep 2014

👍1

shakyShane/browser-sync#241 - Passes builds.
shakyShane/browser-sync-client#7 - Passes builds.

With my local BrowserSync linked to my local BrowserSync client, I am able to see the demos working when running gulp browser-sync.

simshanith on 11 Sep 2014

Thanks @simshanith for nailing this, I'll get it released tomorrow/saturday.

This is why I love open source so much. :)

shakyShane on 11 Sep 2014

My patches should allow for XHR Polling transport with most proxied Socket.IO setups. WebSocket proxying support ticket opened at shakyShane/foxy#2

simshanith on 11 Sep 2014

I have been trying to diagnose a similar issue where window.io is not defined. My solution was to highjack ___browserSync___.io if window.io is not defined. This seems really hacky but it does 'work'.

Any idea what would cause window.io to not be defined? I have my <script src="/socket.io/socket.io.js"></script> defined at the end of my body and have a gulp task set up:

gulp.task('browser-sync', function() {
  browserSync.init(files, {
    logConnections: true,
    logLevel: 'debug',
    port: 3100,
    proxy: 'http://localhost:3000/#/',
  });
});

nathasm on 24 Nov 2014

Thanks for the report @nathasm ! Your issue did indeed arise out of my PR to fix the previous issue. The culprit is found in https://github.com/shakyShane/browser-sync/blob/master/lib/templates/connector.tmpl, compounded by the fact that this script is asynchronously loaded. BrowserSync should do noConflict style loading on window.io; which may be kinda tricky, but doable.

simshanith on 24 Nov 2014

@nathasm I went ahead and opened a separate ticket (#342) for your new issue. I should have a PR submitted today.

simshanith on 26 Nov 2014

Was this page helpful?

0 / 5 - 0 ratings