
Why Is Google Blocking Inbox on Firefox? - diggan
https://gist.github.com/VictorBjelkholm/1d0f4ee6dc5ec0d6646e
======
pilif
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](https://news.ycombinator.com/item?id=8495498)

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

~~~
diggan
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.

~~~
freehunter
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
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
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
"Support cost" doesn't apply only to customer support.

~~~
pbhjpbhj
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
It takes resources (mainly developer time) to ensure that an application is
working properly on multiple browsers. If you read the article you can see
that a simple UA string change does not fix the problem.

~~~
msandford
There's a big difference between "provided a degraded experience in non-Chrome
browsers" and "actively blocking non-Chrome browsers by means more invasive
than UA checking"

Remember, there isn't any kind of really legitimate API for 100% determining
which browser you're running in. There's a lot of ad-hoc methods which usually
work.

These folks spent extra effort to block it from even TRYING to run in FireFox.

How are the FireFox devs supposed to see the bad performance that they need to
fix for Inbox to work right if they can't run it at all?

~~~
sosborn
There is also a big difference between "provided a degraded experience in non-
Chrome browsers" and "you have to actively disable CSP (a global setting) for
it to work in Firefox."

Also, with respect to performance, this comment in the article might shed some
light:

"Also see Bugzilla entry. The use of spare arrays with huge indexes was a
performance issue in Firefox. It's been fixed in Inbox and in FF but not
shipped in FF yet.
([https://bugzilla.mozilla.org/show_bug.cgi?id=1087963)"](https://bugzilla.mozilla.org/show_bug.cgi?id=1087963\)")

------
skywhopper
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
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.

~~~
msandford
I'm sure that there's a lot of that going on, yes.

But Google has the legacy of their "don't be evil" company motto to content
with. Which is to say that people expect (foolishly) for them to at least try
not to appear evil.

The difference between Google prioritizing Chrome vs anyone else is that
Google owns Chrome whereas Apple doesn't, and some random startup certainly
doesn't.

It smells of Microsoft's "we'll only make this work in IE and fuck everyone
else" strategy and that doesn't bring other warm thoughts to mind.

So it's not JUST that it's fashionable to think the worst of Google these
days.

~~~
techrat
You might have an argument if Chrome wasn't open source.

Being that is not the case...

~~~
mikeash
How does open source invalidate that argument?

~~~
techrat
Anyone can build and release a compatible browser whereas one would be stuck
with Internet Explorer (and no compatible browser) if something were only to
work on IE.

As it stands, Chromium exists.

~~~
mikeash
How is it any better that something can run on a bunch of slightly different
versions of Chromium, but no other browsers built from a different base?

~~~
techrat
Chrome isn't the only option. It is not a case where it could be Microsoft
making Hotmail only work in IE, for example.

Don't want Google's services in your browser? Download Chromium or the dozens
of other browsers forked from that codebase.

With something being limited to working in IE, THERE IS NOTHING ELSE, binary
or otherwise.

------
qnk
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](http://googleblog.blogspot.com/2009/12/meaning-of-open.html)

~~~
whizzkid
I think this slide explains everything about how Google has changed the way of
handling their business.

[http://www.slideshare.net/ericschmidt/how-google-works-
final...](http://www.slideshare.net/ericschmidt/how-google-works-final-1)

They are more focusing on managing their business which is limiting their
contributions to open standards.

~~~
skrebbel
Which of the 54 slides?

~~~
whizzkid
Sorry for typo, I meant "slides", but especially second and third slide.

------
Tyrannosaurs
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.

~~~
diggan
What I know, given the right vendor prefixes, transitions works mostly the
same way on both platforms. I don't think it makes sense to only have
transitions for one browser when it's trivial to support other browsers as
well. The CSP issue I honestly don't know why that's so but I'm fairly sure
they should be able to follow CSP on their own domains, just like the rest of
the applications on the web have to do.

To me, it feels like Google has an unfair advantage on doing web applications
when they can do stuff on their own domains that no one else can, unless they
also develop their own browser with unique features.

~~~
couchand
_To me, it feels like Google has an unfair advantage on doing web applications
when they can do stuff on their own domains that no one else can, unless they
also develop their own browser with unique features._

And legally dangerous, too. It's as if they forgot entirely about the half a
billion Euros Microsoft shelled out for doing precisely the same thing.

~~~
gcb0
or they bought the right people this time and are sure to be free from that
fate.

remember that Microsoft wasn't sued out of the blue. competitor companies
lobbied for it. if Google lobbies first they should be fine.

------
transfire
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
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](https://fastmail.com)

~~~
drdaeman
Privacy-wise, personally, I'd just love to see what are my options for self-
hosted email service.

Presently it's just Postfix and Dovecot on the physically-owned server and
Thunderbird and K9 Mail on desktop and mobile. Quite old-fashioned.

I had seen links to some fastmail support branch for cyrus and some jmap.io,
but didn't really get what thase are and all on Fastmail's website suggests
it's a service, not software. But maybe I had missed something.

So... is it for me or not?

------
cognivore
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
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.

~~~
cognivore
Well, yes, that'd be nice if we had a "interoperable universal interaction
standard." But now the majority (and soon, almost everyone) will be using the
internet on tiny personal computers (smartphones) that run native apps. Using
a web browser will become less and less important or even relevant. In such a
case the costs of optimizing for multiple run-times makes little sense.
Really, abandoning the browser for native apps (in the old days we called them
"programs") across the board makes more sense, and leave browsers to what they
were originally intended for - document perusal and simple data collection.

And web browsers absolutely suck at UI for applications. Imagine the man hours
and effort that went into building Gmail. It boggles the mind. Who would even
want to maintain that?! All for something that could have been created as a
native app much easier. There's a lot of reasons that people have gravitated
towards apps on phones, but one of them is assuredly that the experience is
better than using a web browser.

~~~
custardcream
As someone who is old enough to have written "programs" and sees the instant
relationship to "apps", I vigorously disagree. Lets consider these points:

1\. Firstly there are competing platforms on which to deploy your programs.
This means there is little common ground between the three major sectors of
the market. You either have to pick one and lose market share or pick all and
increase cost. Nothing (yet) has solved this problem adequately without
increasing cost or decreasing agility and/or quality and consistency.

2\. Each of these platforms has many barriers to entry from subscription fees,
having to buy specific hardware and learn how to use it, distribution and
vendor costs, QA cost and the risks of rejection and having your product
closed suddenly.

3\. All of the markets are primarily consumer oriented which makes deploying
things to corporate entities a pain in the backside requiring more hoops to
jump through.

4\. None of the programs have longevity, a stable platform to run on, security
guarantees or predictable security evolution.

So at the end of the day, you're pitching programs sold behind a walled garden
by someone who wants a slice of your cash and doesn't give a fuck if the
device works after you've sold it versus a platform with zero entry cost,
total ubiquity and importantly absolutely no distribution or sales model at
all so you can build your own?

Nope.

People take apps because they're cheap, free or the vendor is pushing them.
That's it. If it wasn't the case, the first thing we'd do when we unboxed a
mac or a PC was download and install facebook. Which we don't do.

As for mobile first everything, not a chance.

~~~
TeMPOraL
A small tangent.

> _and doesn 't give a fuck if the device works after you've sold_

Which is even worse on the web, where most of the time that someone also
doesn't give a fuck about you at all _and_ will just pull the product the
moment he gets enough users to make an exit.

There are good things about having a working binary on your device; the author
can't just take it away from you just because he doesn't care about the
product anymore.

~~~
Silhouette
_There are good things about having a working binary on your device; the
author can 't just take it away from you just because he doesn't care about
the product anymore._

Tragically, in the modern software world, that often isn't true either.

Buggy junk gets shipped routinely even when people are paying real money for
it. Software developers assume you'd love to have their regular updates, even
if those updates also change interfaces and modify or even outright
break/remove functionality however they feel like. If you don't apply the
updates, you don't get security fixes either, so for any software that is at
all involved with sharing data or communicating on-line many users have little
choice. The idea of long term support for any stable software that people
actually rely on is a joke for many projects. And that's before we even get to
all the DRM/activation junk.

Ironically, the worst offenders are probably Chrome and Firefox. IME, the next
worst offenders are often the supposedly high-end professional software that
comes with a thousands-of-dollars-per-seat price tag -- assuming you can even
buy a copy instead of renting it these days.

I'm mildly optimistic that a new generation of software seems to be arriving
where people are expected to pay for good work but the prices are much more
reasonable: not App Store peanuts, not Enterprice Pricing (call for a quote,
because hell will freeze over before we publish any useful information
publicly). A lot of these tools are relatively small or specialised, but they
do their jobs well, they get very favourable feedback from users, and they
have real, commercially viable development organisations behind them. Also,
they rarely incorporate the user-hostile junk. So good work can still be done
commercially, and of course for some of the important geek-friendly software
like development tools and OS/server/networking infrastructure there are Open
Source projects that are usefully stable, reliable and comprehensive. I look
forward hopefully to a day when these kinds of projects are the norm for
software we rely on, and we can all get on with using our computers without
constantly fighting with them.

------
josteink
> 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
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.

~~~
gcb0
yes. and much more.

for example, even when using open source web kit or chromium they actively
removed all options to disable referrer.

go on. try to find it on your current chrome build. or even on chromium thanks
to their legacy.

then remember that referrer with its most exposing setting is required for
Google to monetize both their organic and paid search.

~~~
lkbm
The only way to do it in Firefox is through the scary and arcane about:config
(or an extension). Historically, methods to remove that have not been provided
by browsers, whether Google-developed or not. I've always done it via Privoxy,
never the browser.

~~~
gcb0
> scary and arcane

i use it every day.

even on firefox mobile!

and it serves my purposes just fine. not to mention you are not exactly right.
as you can update those values via user scripts that can be easily distributed
or even made as an extension that change those values for you and/or provide a
new settings controller UI.

~~~
lkbm
Yeah, and I use the command line every day. Whenever people see it on my
screen, they think I'm "hacking".

There are Chrome extensions to do it as well. The point is, the lack of a UI
control usable by the average user is not some Google conspiracy. It's always
been the standard in pretty much all browsers.

------
manishsharan
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
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.

~~~
couchand
Except that with a few quick changes the application ran, so intentionally
blocking seems like a valid description.

~~~
Blahah
Changes that included disabling a browser security policy - not something it's
reasonable for Inbox to request its users to do.

~~~
couchand
But serving all content from a single domain is a reasonable thing for Google
to do.

------
juanmnl
Because, you know, "Best viewed in Chrome" is a thing, and somebody is
becoming the new IE. It's saddening.

------
mintone
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.

~~~
couchand
Or, you know, a third option. They could always do what _every other web
developer must_ and make their software progressively enhance so it works at
the very least on a few major browsers.

~~~
mintone
And I absolutely expect them to do that, but when you have a platform you know
works well with your software then you'd rather get to market there and then
once you have everything working across the board release for all. Again, as
every web developer must, release a beta that works under x specific
circumstances and then fix for all resulting in your v1.0 product. If you
don't do that then time to market doubles or more.

------
SimeVidas
A $400B company cannot get their app to work securely & performantly in
Firefox, so they’re blocking access via UA sniffing. Seems legit.

~~~
Kalium
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.

~~~
SimeVidas
Achieving web compat with Firefox (and possibly other browsers) is not a wise
use of resources? What?

~~~
Kalium
For an initial beta release on a product with no revenue gains? Yeah, probably
not. For later releases? Sure.

~~~
SimeVidas
Like accessibility, web compatibility is harder to achieve (and requires more
resources) when addressed late in the development process. A web app must be
accessible and compatible with the major browsers, so ensuring this from the
start is the optimal approach.

~~~
Kalium
And it's clear that they were looking at it from the start. If you read around
a bit, you'll see that they ran into a particular performance problem with
Firefox. They're working to solve it, but decided they could release something
usable for Chrome users immediately.

~~~
SimeVidas
Still, I suspect Google’s developers are too focused on development in Chrome-
only. If true, this may have contributed to perf issues arising in Firefox, in
the first place. I also suspect that Google’s web compat team is not
sufficient to handle their products.

~~~
Kalium
Did you read the clearly documented technical details? Basically, array
slicing on sparse arrays in Firefox is much, much slower than on Chrome.

It's not a matter of lacking competence or skills or anything of the sort.
It's a basic question of what level of resources you are willing to put into a
product before you have something to beta-test. Inevitably, that's less than
the amount required to be perfect in every aspect.

~~~
bzbarsky
> array slicing on sparse arrays in Firefox is much, much slower

You mean "was", since it's fixed?

> It's not a matter of lacking competence or skills or anything of the sort.

Yes, it is. Not reporting a bug when you run into it but instead just
complaining about it is in fact lack of competence.

Arguably using super-sparse arrays in JS is also lack of competence, but the
other is much more obvuous.

> It's a basic question of what level of resources you are willing to put in

Filing a bug takes about 5 minutes.

------
spindritf
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.

~~~
frandroid
Whoa, good to know. But considering that the product is beta, they probably
want to test it on regular free customers first...

------
Siecje
It is not just Inbox

[http://www.otsukare.info/2014/10/28/google-
webcompatibility-...](http://www.otsukare.info/2014/10/28/google-
webcompatibility-bugs-list)

------
ausjke
I removed chrome from both linux and windows and use Firefox all the way. If
no Firefox, then I'm just walking away.

------
hokkos
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.

~~~
gcb0
why do you even bring that up?

also, unless you know what's on that memory and also tell us about total ram
I'm just writing this off as anecdotal cache usage.

------
GrinningFool
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?

------
dksidana
TLDR: 1. Inbox currently using XSS right now, it is disabled by default in
firefox. Refer: [https://developer.mozilla.org/en-
US/docs/Web/Security/CSP](https://developer.mozilla.org/en-
US/docs/Web/Security/CSP) 2\. Firebox has option to enable XSS, so inbox can
work on it. But that allows XSS attacks.

------
SimeVidas
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
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.

~~~
dblohm7
Yet they didn't file a single bug against Firefox!

------
mark_l_watson
Key quote from article: ""It's slow, a lot slower than Google Chrome.""

So, InBox (which I really like by the way) is a rapidly developing project and
the team only wants to optimize for their own Chrome browser during rapid
development -- this seems really reasonable to me.

If InBox does not run well on Firefox and Safari a year from now, then the
author of the article would have a valid complaint.

------
bgarbiak
Out of curiosity: does it work in Opera?

------
JoseVigil
There is always a conspiracy theory on everything Google does. I think this
has nothing to do with that.

Besides, everyone that has a startup and fresh ideas is always "afraid" of
Google next step not stepping on top of its startup.

This generates paranoid among us, its natural given the size of Google.

------
hellbanner
I want to point out that a while back Apple seemed to "block" \-- or at least
not implement -- iOS apps uploading on Chrome or Firefox. The page would just
stall loading forever, but it worked in Chrome.

------
tedchs
tl;dr: here are a couple stabs at why, but I still don't know.

~~~
tedchs
I don't understand the 4 downvotes. The blogger himself says "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."

------
kailuowang
When you decide whether to release a product on a certain environment, it's
not as simple as something like:

a) if it works, or seems it would work, on that environment, then we should
release it there.

or b) that environment is a competitor, so we shouldn't release it there.

If you think it should be that simple, you never worked with a real product
manager responsible for products with millions of users.

Having a product to support a new environment isn't a trivial effort for devs,
QA and a bit design. At a particular stage of the product (think about the
goals they want to achieve for Inbox at this stage, which I think is something
along the line of polishing the product based on mass but controlled
feedback), I would've probably made the same decision if I were the product
manager.

~~~
gcb0
just like Microsoft was praised for releasing their OS with a free, supported
browser. with all the development and qa done for free...

