top | item 8606879

Why Is Google Blocking Inbox on Firefox?

213 points| diggan | 11 years ago |gist.github.com

208 comments

order
[+] pilif|11 years ago|reply
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 performance issue with accessing sparse arrays with huge indexes.

Link to the post: https://news.ycombinator.com/item?id=8495498

Link to the bugzilla entry: https://bugzilla.mozilla.org/show_bug.cgi?id=1087963

[+] diggan|11 years ago|reply
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.

[+] iamchrisle|11 years ago|reply
FWIW, Safari (webkit) is mostly working. IE is, unsurprisingly, a train wreck.
[+] userbinator|11 years ago|reply
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|11 years ago|reply
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....
[+] skywhopper|11 years ago|reply
Any time you see a comment like "With some more man hours, it seems trivial for Google to get the application to run in Firefox", you know the author either doesn't know what they're talking about or just hasn't thought about it very much. Anyone who's done any serious web-app development in the past decade knows that cross browser compatibility at the bleeding edge (ie, past what the JS frameworks have worked out) can consume as much time as the rest of the application put together.

At the early fast-iteration stage of a limit-seeking webapp like Inbox, it makes sense to focus on the app itself and limit yourself to just one browser. For Google, obviously they will choose Chrome. Once the app reaches some stability, and major changes are coming far more slowly, then it makes sense to start working in cross-browser compatibility.

[+] TeMPOraL|11 years ago|reply
I think that most of those comments stem from Google-hating, which is currently a big fashion here. Were it Apple doing it, they'd be lauded for their attention to user experience. Was Inbox a product of a random startup, it'd be praised for good business approach and proper prioritizing of developer time. But it's Google, so it must be some evil plan.
[+] diggan|11 years ago|reply
> Anyone who's done any serious web-app development in the past decade knows that cross browser compatibility at the bleeding edge (ie, past what the JS frameworks have worked out) can consume as much time as the rest of the application put together.

Sure thing. As a web developer, I also know that I NEED to follow CSP on every application I do. Something Google doesn't seem to do when running in Google Chrome.

I also know that adding two prefixes along with another prefix, isn't that hard to do.

If you want to be early, fast and get feedback, make sure your application works for more browsers than your own in-house browser. Because when you release it, people will surely use other browsers than your in-house browser.

[+] ppereira|11 years ago|reply
That is a great technical argument, however, the reason this has attracted so much attention is because this product is about email. Email plays such an important role in our modern lives that any announcement hinting that Google is moving towards vendor lock-in for email access is going to attract scrutiny -- regardless of whether it is by innovative features, enhanced performance, or browser lockout.
[+] msabalau|11 years ago|reply
To build upon that, it's worth noting the context: a public beta that's only a few weeks old.
[+] Bahamut|11 years ago|reply
This is an extremely naive comment. While cross-browser testing does take work, it makes an unfair assumption about the experience & knowledge of some of us commenting. Diggan (the user who wrote the gist) is not a regular person - he is an experienced and knowledgeable web developer (I don't necessarily agree with all his opinions, but I do respect his knowledge - I have previously had a vigorous conversation with him on IRC on some technical stuff). When I said CSP and animations are "trivial", it isn't without having had experience doing just that.

As someone who has had to work on teams and who now leads teams on apps with cross-browser functionality (and native mobile via Cordova), I get the challenges. Google definitely has the resources to meet them though. Time is just the x factor, and with this sentiment, I agree with. I have no problems with what Google did here - I merely made observations.

[+] pcwalton|11 years ago|reply
> At the early fast-iteration stage of a limit-seeking webapp like Inbox, it makes sense to focus on the app itself and limit yourself to just one browser. For Google, obviously they will choose Chrome. Once the app reaches some stability, and major changes are coming far more slowly, then it makes sense to start working in cross-browser compatibility.

Would you also agree that it would be OK for Microsoft to create products that only work in IE, then, and to advertise IE whenever you try to use those products?

[+] unknown|11 years ago|reply

[deleted]

[+] qnk|11 years ago|reply
Google is not the same it wanted to be back in 2009 [1]:

Today, we base our developer products on open standards because interoperability is a critical element of user choice.

[1] http://googleblog.blogspot.com/2009/12/meaning-of-open.html

[+] custardcream|11 years ago|reply
Yes. It's now Microsoft circa 2001.
[+] Tyrannosaurs|11 years ago|reply
The last paragraph:

"However, we still haven't figured out exactly why Google is blocking Inbox on Firefox. That the application is not working, seems to not be fully true. With some more man hours, it seems trivial for Google to get the application to run in Firefox to. Maybe too much Chrome specific technologies or just a try to limit the usage of Firefox on the web?"

Is odd as he's spent the rest of the article pointing out that there are bits of missing functionality (such as transitions), he's disabled CSP which worries him and that there are errors showing, and that's just what a relatively brief review found. Given what is listed it seems pretty straight forward to me that in it's current form it shouldn't be supported on Firefox.

[+] transfire|11 years ago|reply
Google's attempt to take over email does not sit with me well. We need better email. But email is too important to be proprietary. We need open standards here. And we need open source developers to kick it in high gear to create better email clients.
[+] couchand|11 years ago|reply
In case you haven't seen it, you might consider Fastmail [0]. They have a great webmail client, they just released native mobile apps (for both iOS and Android at the same time, wow!), and they are very much working to expand the standards to meet the needs of modern e-mail.

[0] https://fastmail.com

[+] Oculus|11 years ago|reply
I don't think the issue is as much with the clients as it is with the spam filtering Google provides. The sheer volume of emails they handle allows them to have the best spam filtering in the world. Something, that will be very difficult to duplicate through OSS.
[+] pjc50|11 years ago|reply
There's no shortage of mail clients. There's even a decent choice of webmail clients. But Gmail offers free hosting with decent antispam, which are things that otherwise cost money.

Unless people want to get syndicalist/cooperative with their email, they'll go with the large free email providers.

[+] debacle|11 years ago|reply
Since you can be pretty sure that Google reads and hands over your email just as much as Microsoft does, you should give outlook.com a chance. It has a really nice UI for personal email and, apart from a few UI deviations, is pretty much the same as Gmail was before they started trying to make it "better."
[+] cognivore|11 years ago|reply
There's not really a good reason for Google to make applications they create work outside their own run-time environment - Chrome. Any technical reason they might offer (sparse array performance) is just facetious. They have the technical know-how to solve such problems, but business wise it makes little sense.

I use three web browsers for just that reason. Chrome for Google products (YouTube, Gmail, now Inbox, etc.), IE for Microsoft products (Outlook.com, etc.), and Firefox for the open web and general usage.

[+] custardcream|11 years ago|reply
Yes there is. It's the world wide web. An interoperable universal interaction standard. Or it was until Google started pulling an IE6 game.

I use Firefox for everything because there is no central motivation to specialise. If a site doesn't work well, it doesn't get my business.

[+] microtonal|11 years ago|reply
Any technical reason they might offer (sparse array performance) is just facetious. They have the technical know-how to solve such problems, but business wise it makes little sense.

Indeed. They cared about open standards when Microsoft was still dominating and the new categories were in their infancy. Later, they cared because Apple dominated smart phones and tables for some years. But now that Android has an ~85% worldwide marketshare, Google Mail is probably the most popular e-mail provider, and Chrome made serious inroads on the desktop, they feel confident enough to slowly start ignoring standards to lock other browsers and ecosystems out.

Of course, the historical difference compared to Microsofts rise is that hackers always had contempt for Microsoft, while Google is loved in large contingents.

[+] voyou|11 years ago|reply
"There's not really a good reason for Google to make applications they create work outside their own run-time environment - Chrome"

Except that the only reason Google built a run time environment in the first place was to encourage people to use their services - that is, the things that collect the data and serve the ads that make them money.

Google has no business reason to block Firefox; quite the opposite, in fact. So it's reasonable to believe them when they say they have a technical reason.

[+] Bjartr|11 years ago|reply
>They have the technical know-how to solve such problems, but business wise it makes little sense.

In this case, the business priority was a release coincident with Lollipop.

[+] Kalium|11 years ago|reply
There are always more problems that you can solve before you release a product. This is universally true of all products. It doesn't matter how developed the thing is, there are always more things you can do.

But at the end of the day, you do need to ship a product. Which means some of those go un-done. Especially when it's a product in beta where you're looking to get feedback and iterate.

[+] josteink|11 years ago|reply
> I'm not 100% sure on how the browsers implementation differs with CSP but there is a main difference in that there seems to be no CSP protected between Google domains in Google Chrome

If this is true, does this mean that Google is short-cutting internet-security for their own applications in their own browser?

Or am I reading this all wrong?

[+] johnward|11 years ago|reply
That's the way I read it too and I'm surprised no one else has mentioned this. Unless I'm missing something Google is allowing XSS for their own domains in chrome.
[+] manishsharan|11 years ago|reply
I subscribe to Google Apps for Business ( Gmail, Calendar etc.) The Google Admin console for my company is barely functional in Firefox. Switching menus causes the page to crash and Firefox prompts me to stop the scripts. On the other hand , the same console works fine on Chrome. One could argue that this is because FireFox "is not as fast as Chrome and I should use Chrome if I use Google Web applications". Hmm -- I do recall hearing a similar argument sometime in the 90s.
[+] jaimeyap|11 years ago|reply
I think the term "blocking" is a bit misleading. It implies they have it running properly in FireFox and are going out of their way to make it only run in Chrome.

It seems more likely they had an aggressive plan to ship inbox across Web, Android and iOS. And they started with "Chrome only" to save development time. I'm sure support for other modern browsers will follow soon.

[+] diggan|11 years ago|reply
Yes, it is indeed functional in Firefox, with some adjustments to their animations, it would be "running properly". And yes, they are going out of their way to make it run only in Chrome since all the rest of the browsers are blocked.
[+] couchand|11 years ago|reply
Except that with a few quick changes the application ran, so intentionally blocking seems like a valid description.
[+] juanmnl|11 years ago|reply
Because, you know, "Best viewed in Chrome" is a thing, and somebody is becoming the new IE. It's saddening.
[+] mintone|11 years ago|reply
Google have produced a product which offers a great experience on one browser. They are happy with the performance of the application on that browser. They have no doubt tested it on other browsers and found the performance to be sub par. That application is clearly still in 'beta' mode (The app is still invitation only). I am sure that they will 'un-block' the browsers that Inbox doesn't perform well on once they've resolved the performance issues - I'm sure it's also not a slight against Firefox or any other browser. The alternative of course is that instead of this discussion thread we'd have a thread about how poorly Inbox performs on firefox which would damage the products overall reputation.
[+] SimeVidas|11 years ago|reply
A $400B company cannot get their app to work securely & performantly in Firefox, so they’re blocking access via UA sniffing. Seems legit.
[+] Kalium|11 years ago|reply
Release early, release often, iterate fast. Google's doing these things.

Just because you have the resources to do something doesn't make it a wise use of resources.

[+] spindritf|11 years ago|reply
Because they don't want a slow webapp under their logo. And this one would be particularly handicapped by that.

Everyone praises Apple for user experience, right? There you go. They're giving you want you want. And at least Chrome works on multiple platforms, even Linux.

What seems like a more arbitrary limitation is that Inbox doesn't work with Google Apps. Thought it, too, probably has some technical reason deep in the belly of the beast.

[+] ausjke|11 years ago|reply
I removed chrome from both linux and windows and use Firefox all the way. If no Firefox, then I'm just walking away.
[+] hokkos|11 years ago|reply
Google Inbox is using between 365MB and 460MB, when Ghostery and Add Block Edge is activated, it is more than 600MB. This is where multi process seems to be useful (otherwise it is using much more memory for no real gains), and extensions can be really taxing sometimes.
[+] GrinningFool|11 years ago|reply
This is a good exploration of how the blocking is being done.

As far as why, it seems self-explanatory. They're not ready to support other browsers yet. Why does this need to be a thing?

[+] SimeVidas|11 years ago|reply
1. Develop app specifically for Chrome

2. Wonder why it doesn’t work well in Firefox

3. Block Firefox via UA sniffing

4. Disband web compat team and use money on NASA hangers, balloons and robots

5. Profit

[+] Bahamut|11 years ago|reply
For those who did not see my comment in the gist, I'll paste it here:

"Probably the performance threshold Google has for its consumer facing products - if it runs slow on Firefox, then it would have normally have been a release blocker."

Google cares probably the most out of any tech company I have seen about performance, especially with any consumer facing apps.

CSP would probably be trivial for Google to fix. Animations/transitions similarly so. The only real explanation that makes sense is performance.