7 ms·

On the HN thread accompanying the release of Google Inbox, a (supposed) engineer working on Inbox was saying that the reason for the exclusion of Firefox was a

• diggan 12y ago
  Thanks a lot for that information! Will include it in the post when I get a chance. The performance is kind of bad in Firefox but I'm not sure it justifies blocking the entire browser because of that. For a comparison, Google Photos is slow as hell in Firefox, but you could still use it if you want to.
  • phpnode 12y ago
    If they'd supported Firefox from the start everyone would be slating them for "crippling" Firefox, or they would have had a poor user experience that would turn a non trivial percentage of early adopters off the entire product. They cannot win here, it was a bug in FF, it is now fixed, presumably they'll stop blocking when the fix is more widely available.
    • shadowmint 12y ago
      They could have made the effort to make this work on firefox from the start, but someone decided the effort wasnt worth it. The 'would have been bad experience to new users' is a strawman arguement. Solution: dont release product until it works. Firefox is fast enough if you write code with it in mind. ...but hey, who cares about anything except chrome right? If someone visits play.google.com on an ipad and safari crashes screw them for not using android right? Its Business Politics at play, not technical restrictions.
      • aroberge 12y ago
        If it had worked in Firefox and Chrome, but not on Internet Explorer, what should they have done? Think about that...
      • andybak 12y ago
        > Its Business Politics at play Or alternatively it's economics. Maybe someone, somewhere had to make a decision similar to "If we want a good experience that includes Firefox users from day 1 it will cost $x and delay launch by y weeks". And he had to sell that to his boss. Even in a company as awash with money as Google, someone has to justify budget choices.
      • Tehnix 12y ago
        >The 'would have been bad experience to new users' is a strawman arguement. Solution: dont release product until it works Not really. And here's a list of arguments why it's okay to focus on one browser (at least at first): 1) It's in beta, so you want to get it right before focusing on making it work everywhere 2) Developing for multiple browsers adds overhead to developers. I imagine they like to utilise some experimental webkit features, which are either not available in Firefox/gecko 3) Related to 2), they would add a lot of overhead making sure the UI and UX is the same, using multiple vendor prefixes and workarounds for other things. And just to point out, >dont release product until it works is probably the worst advice ever to give to people. You want people to actually test your application. You can never catch all the edge cases that can/will happen, in your mind, and sometimes your assumptions are wrong. This is a pretty basic concept or Lean UX etc.
        • abraham 12y ago
          *experimental Blink features
        • Touche 12y ago
          My counter is that "fix it later" never comes. Unless business sees browser support affecting the numbers they will not allocate the time to fix it. Some dedicated developers might fix it by working over time but that's essentially free labor. It has to take a strong engineering department to say "we will not ship until it works".
    • akavel 12y ago
      In other words: performance is a feature. And thus, not wanting to ship a product with an important feature missing should be understandable.
      • louthy 12y ago
        Quite. Performance is definitely a feature of Google Inbox and it's very much appreciated. I think it's an excellent tool, and the rapidness of action responses is definitely a huge part of that.
    • danielweber 12y ago
      This is an ancient lesson in software development. IIRC back in the early 1990s there was a beta build of Microsoft Office sent out to early adopters with full debugging turned on, and one of them wrote a newspaper review about how slow the new version was, despite the adopter being explicitly told it was a debug build and would be slower. "It's just to show off new features, not new speed."
  • freehunter 12y ago
    Google blocked Windows Phone from accessing Google Maps in the browser (both the desktop and mobile versions) with the claims that IE was unsupported, even though Google Maps UK worked just fine. Google does have a history of blocking browsers they don't support, no matter how functional it may seem.
    • Touche 12y ago
      Yeah, they seem to use the whitelisting strategy for all of their properties. If something isn't QAed it doesn't get enabled. I suppose at that scale the support cost isn't worth the "let them use it in a degraded way" mantra most of the web community follows.
      • msandford 12y ago
        SUPPORT COST?! HA HA HA HA HA! You can't get support out of Google at any price, unless you're an advertiser. But in that case, it's only help for your ads and nothing else. You can't talk about "support cost" when it's zero.
        • sosborn 12y ago
          "Support cost" doesn't apply only to customer support.
          • pbhjpbhj 12y ago
            Go on, I'm interested - what extra cost do Google have if I use the same service in FF as I would otherwise have to switch over to Chrome to use; given that they say up front that other browsers aren't supported and that this is a beta so expected to be shonky. What cost is there? If I've switched UA string Google might not even be able to tell, without actively seeking out the information, that other browsers are using it - how then could that be an extra cost? School me, please.
            • sosborn 12y ago
  • res0nat0r 12y ago
    Don't say "blocking" (or maybe that is preferred since the tone of the post is to insinuate Google is being evil) and say "not supported yet" since the product is still in beta.
    • mikeash 12y ago
      To me, "not supported" means that no effort has been put into making it work and you can't expect any help, but also that no effort has been put into not making it work. If the only problem is performance, then "not supported" would imply that it can be used, but it will be slow and you shouldn't complain about it being slow because you're doing something to supported. If there's code explicitly added to make it not work on Firefox, then "blocking" is a perfectly good word to use.
  • dblohm7 12y ago
    I'd also like to point out that, if you read the bugzilla bug, it was fixed on the same day that it was reported! Nobody from Google bothered to file any bugs against Firefox; it wasn't until a Mozilla engineer saw the Google engineer's complaint on the HN thread that he filed it and fixed it himself!
• iamchrisle 12y ago
  FWIW, Safari (webkit) is mostly working. IE is, unsurprisingly, a train wreck.
• userbinator 12y ago
  performance issue with accessing sparse arrays with huge indexes ...what? Why would they need "sparse arrays with huge indexes" anyway? This sounds more like a problem with the developers doing something ridiculous, and not the browser. Maybe Chrome is faster at it, but that's like saying "compiler X has a performance issue with bubblesort." More precisely, I'd like to see what exactly they're trying to do with this sort of code. Optimising "sparse arrays" sounds like matrix algebra and scientific computing, not an email client.
• bzbarsky 12y ago
  It should be noted that the Inbox folks didn't bother to report the issue, and that once it was reported it was fixed within a few hours....