Hacker News Reader

Comment by drivebyacct2 | Hacker News Reader

Yet another reason Chrome's rolling release auto updates are glorious. (When the protocol is fixed, Chrome users will all have it within a day or two; Firefox users, not so much)

Additionally: Nochum's comment is concerning, if accurate:

>This is gonna suck since the feature detection will be totally thrown off.

>E.g.:

>if (WebSocket in window) > ...

View on HN

Relying on feature detection alone for WebSocket is a big mistake though. Websocket can fail for a number of reasons - proxies, stupid ISPs that interfere with HTTP traffic etc.

In Mibbit, the code is something like this:

  if(WebSocket in window) {
    tryWebsocket();
    window.setTimeout(function() {
      if (nothingHappened()) useComet()
    }, 5*1000);
  } else {
    useComet();
  }

Where comet in this case is keep alive long polling XHR.

That's an interesting way of managing timeouts. Is the 5*1000 intended to just be a more readable way of specifying seconds?

I assume so. I do the same thing.

Closure compiles it down to 5000 or 5E3 or whatever is smallest in my build process, so all the browser sees is '5e3'.

I find 5*1000 most readable in my source code though.

How can you check if nothing happened?

By changing some global variable in the callback and checking if it has changed in 'somethinghappened' (which only gets called after 5 seconds, giving the callback time enough to get called).

Libraries like Socket.IO will detect if the connection can be made or not... so this point is moot.

Feature detection first, connection detection second, then start degrading the transport until all options are exhausted.

Sure. I was just explaining for those who prefer to write things like this themselves.

Not true. Firefox has auto updates, and will be pushing websockets the moment it gets fixed. Firefox also has the best record for turnout time on security fixes (many being released two days after report), so I doubt that will be slow.

From: http://hacks.mozilla.org/2010/12/websockets-disabled-in-fire...

"Once we have a version of the protocol that we feel is secure and stable, we will include it in a release of Firefox – even a minor update release."

I don't know what you're calling not true. I never suggested that Firefox wouldn't fix this in a x.1 revision. My point is more than 14% of Firefox users are using a version lower than current stable (and that's not counting who is in the [3.6.0, 3.6.12) range.

Isn't Firefox 4 where Mozilla want to start using silent updates?

Firefox is just playing catchup these days, isn't it? Don't get me wrong, that's fantastic. I think everyone benefits from auto-updates.

Yet another reason Chrome's rolling release auto updates are glorious.

I like Chrome's silent updates, but the only real difference between it and Firefox is that Firefox informs the user that the update is being applied. Other than that, I'm not sure what you're referring to.

Chrome updates much more frequently and I think you discount the amount that users ignore the update warnings.

Of course, the people who know what Chrome is are not the people that ignore the warnings.

Couldn't disagree more. You'd be shocked at the number of CE/CS majors that ignore Firefox updates and complain about them. My mom uses Chrome on my parents' laptop and my dad uses Firefox. Guess which one is out of date :).

Absolutely. I hadn't used one of my PCs for a couple of months and turned it on earlier today to find Chrome was two versions behind (7 vs 9).

Reply on news.ycombinator.com