Why Is Google Blocking Inbox on Firefox?
gist.github.com
gist.github.com
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
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.
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.
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.
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.
If you plan to support cross platform, do so from the start.
You can argue about feature parity and 'first user experiences' all you like, but practically speaking, if you don't support the target platforms from the start, you're dooming yourself to FOREVER have 1st class and 2nd class platforms.
You see this all the time in apps; flagship on iOS, rubbish half implemented android version that launches 6 months later and never always gets updates 3-6 later, broken, with bugs. Or vice versa.
I'm not in any way saying that you should to be cross platform, or what platforms people should support. That's a business decision each business has to make. ...but it's not a technical decision. Technically, if you know what platforms you support from the start, you can implement the product with that in mind.
I've literally only ever heard this sort of ridiculous rhetoric from people who've never suffered through retroactively having to go back and support additional platforms. I dare say, business people who make decisions but don't have to actually deal with the consequences of them.
I honestly feel for the Inbox team. I'm sure there a lot of really tedious days ahead of backporting and bugfixing ahead for them (if google decides to make firefox support a thing).
Maybe in GUI applications, but not so much in web browser applications.
>If you plan to support cross platform, do so from the start.
You are already close to automatically supporting all platforms. The point of "not supporting" a browser, is to avoid tedious and time consuming testing of said browser, because CSS and JS works differently in every browser (although close to the same in webkit browsers like chrome and safari).
>I've literally only ever heard this sort of ridiculous rhetoric from people who've never suffered through retroactively having to go back and support additional platforms.
Again, your arguments might apply to a OS application, but not to web browser "applications".
Generally, I also subscribe to the mindset of: make it right for one OS. Instead of: make it shit for all OSs, but usable.
Finally. Going out of your way to support platforms that _might_ be used, for an application that you don't really know if people will use in the first hand, is absolutely idiotic.
You need to know how, why and if people actually will use it, before spending time and money on supporting multiple platforms/browsers.
Just to finish of,
>I've literally only ever heard this sort of ridiculous rhetoric from people who've never suffered through...
I've literally only heard this from people that have never developed for multiple platforms, and expect that "once it works on X, it must work on Y". It just isn't so. Implementations, however neat, always differ in GUI-land.
I can only recommend you seek additional input from your immediate peers before writing your next web 'application'.
(hint: the considerable negative feedback re inbox not working in firefox is the kind of bad press companies would rather avoid)
I believe many people know and understand that it's not unheard of for Google to release app updates on iOS a couple of weeks before the Android version comes out.
And while I've wanted to visit app stores cross platform to add items to a wish list while on the go, and been a little frustrated by not being able to do so, it does seem like a bit of an edge case. Although I suppose with both iTunes and Google Play edge cases can still be huge.
Except that almost no one does it nowdays. MVPs, early launches, etc. Why Google should be held to one standard while every "innovative startup" is held to a completely opposite?
By the way, did no one read what Google itself has to say about Inbox? It's explicitly stated as not a replacement for GMail. They're playing around with UX idea. You can look at it as a very elaborate A/B test.
Google does have a history of blocking browsers they don't support, no matter how functional it may seem.
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.
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.
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?
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)"
When you get bug reports from internal customers it's never "the site isn't working in Firefox 33 with all extensions turned off. It loads but is a little slow.". The bug report you get is simply "it isn't working, you get a blank page".
Answering those types of emails cost real money.
I recall back in the IE5 days that IE on Mac was a significantly different beast than IE on Windows despite being named the same.
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!
...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.
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.
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.
These comments really are just FUD and hating (jealousy?) on Google for ignorant reasons.
Google, on the other hand, has done a lot for open standards and interoperability.
Is it unreasonable for people to flip out on Inbox while it's still very much in beta? Sure. If it's a real beta. Gmail was in beta for what, 5 years?
Does Google have any obligation -- moral or otherwise -- to make Inbox work cross-browser? None whatsoever.
But them not doing so would constitute a break from past policy which is something that people are worried about.
Being that is not the case...
As it stands, Chromium exists.
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.
Providing backwards and parallel compatibility is a secondary concern.
And this is exactly why people are worried about things like this. Google has, depending on who you ask, somewhere between a quarter and a half of all desktop browser usage share. They're the browser shipped by default with Android nowadays, and Android is a big part of the mobile and tablet market these days. By the same token, Google is a huge part of the Internet -- Google runs many of the most popular sites, and is also probably the single-largest source of referral traffic for the vast majority of websites.
And now, you're saying that Google views pushing the bleeding edge in the browser for its browser-based applications is more important to Google than being compatible with other browser implementations. And you wonder why people are starting to worry about Google?
Overall, they have really solid products that have been incredibly useful to me, and you can see how they are working hard on so many important things: surpassing apple on the mobile design front with material design, cranking out bleeding edge and experimental innovations like self-driving cars and glass, and even working on a lot of projects that help to bring technology to those who don't have it, like project loon, the lower cost and open source android stuff, etc -- and these projects have actually been making a really big difference in third world countries (with no strings attached unlike facebook's total bullshit "charity" initiatives).
I'm not a google fanboy by any means. I more or less just use gmail and calendar, and just got an android phone after having an iphone 4 for like four years just to try it out. Just pointing out things I have passively observed about how they run. I would really love to hear the other side of the story though to perhaps balance my perspective a bit more!
Did they ever pull a Facebook-esque social experiment by trying to limit what you saw in order to manipulate your feelings over the course of a day?
Do they sell personal information about you for other companies to use however they please?
Think about this a little bit before you respond with a generic, mouth frothing "BUT GOOGLES SELLS YER INFO" when they actually don't. They sell access to you when you are exposed to ads. Not access to your info.
I'd also like to point out that the drama around Facebook's social experiment was totally overblown. People essentially mixed up what Facebook did (something not unlike an A/B test) with what some imagined Facebook in theory could do (silently but significantly influence emotional state of users), and after articles started calling this "manipulating your feelings" the Internet totally lost it. After all, the extent to which Facebook "manipulated your feelings over the course of a day" is much smaller than, say, 9gag's or that of a television ad.
This is the same problem as the one you're complaining about here - generic accusations about totally overblown things.
An exact example of the false equivalence fallacy.
Personally, I am beginning to fear that the whole idea of privacy starts to block progress and in the end we'll have to choose between the two. Apart from the dystopian future everyone fears, there are also astoundingly huge amounts of good things that can happen thanks to data companies like Google or Facebook collect.
Bullshit actions in partnership with Apple: http://pando.com/2014/03/25/newly-unsealed-documents-show-st...
And, to me, the worst - Bulling the CSS WG: http://lists.w3.org/Archives/Public/www-style/2014Feb/0103.h...
If a random startup does it, they don't have the same conflict of interest as a maker of a major browser does, so there's no reason to expect the reaction to be the same.
I think skywhopper hit it on the head. Just good ol' abuse of the word "trivial" and an underestimation of how much work is needed to finish the last 1%.
I think that - like often is on the Internet - scrutiny can be attracted too soon. Google stated clearly that current Inbox is not a replacement for GMail. Such "vendor lock-in" can currently be completely explained with the fact that they're just playing around and testing if people like new UX.
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?
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.
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.
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://www.slideshare.net/ericschmidt/how-google-works-final...
They are more focusing on managing their business which is limiting their contributions to open standards.
I suspect we'll see a new 100% managed code IDE in the next 3-5 years that will fit this area nicely. It'll have bits of Visual Studio in it and it may even be called Visual Studio but it won't be what we have now.
--As people pointed out, this isn't true. I was confused by Ars Technica's headline declaring VS to be "cross platform".
http://arstechnica.com/information-technology/2014/11/visual...
AFAIK only .net will which is not visual studio.
http://arstechnica.com/information-technology/2014/11/visual...
I think to be honest that some of the stuff Microsoft have been working on behind the scenes is probably scaring the crap out of Apple and Google. There's not been a platform as holistic and complete as Microsoft's offerings so far and they are adding REAL value daily rather than just moving the chess pieces to great fanfare.
Oh and most problems are solved or canned so all we're doing is gluing things together and making it look pretty (which is what programming via abstractions is all about).
I would rather say it has become apparent over the last year. I say windows 8 marks the moment.
That's where Microsoft realized they needed to garner goodwill and at that point Google had so much global market share (web traffic, browsers, mobile) they could say fuck all to everything and anyone.
And they started doing just that. Anyone else remember the forced and sneaky adaption tactics that was Google+?
I actually like the "new" Microsoft and the direction it's heading, and I'm still trying to wrap my head around that fact.
Really much ado about nothing here.
And no, Google does not keep emails. After 30 days you cannot recover anything.
https://support.google.com/a/answer/112445?hl=en
>If you can't find your messages in All Mail, Spam, or Trash, or by performing a search, then they've been permanently removed from Gmail, possibly deleted by someone else. We regret that we are unable to recover messages that have been permanently deleted.
I can confirm that having emails permanently deleted, such as when I unsubscribed from mailings from a store I deleted my account from... I stopped receiving advertisements in the sidebar related to that store. When you stop getting ads about specific things after deleting all emails about those specific things, I would say that's fairly conclusive.
"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.
They're short cuts you might take to get a product out and get early feedback, the same sort of shortcuts most of us have taken when pushed to release something sooner. This is a product in Beta, not the finish article.
Even if everything work in theory just dropping multi-browser testing would save time. If their aim is a beta product for early user testing, I really don't think what they've done is unreasonable.
It's not like the application is completely broken in Firefox with the fixes mentioned. Bypassing CSP for your own domains feels like a hack that you shouldn't be able to do.
Remember with this sort of product the questions they have are "is this interesting?", "is this useful?", "do people like what this does?".
Can we get this running on Firefox simply isn't an interesting question to them - they know the answer, it's yes if they throw resource at it, but for a new product team with questions over whether this product should even exist that's not a priority.
Remember, this is Google who have a long history of canning this sort of project. If I were the company who produced Wave, I'd probably look at how I could reduce the cost and time to feedback for my next new thing too.
As an aside, I've tried Inbox and, to me at least, it's the next Wave, not the next Gmail.
And because of that there is the risk of reputational damage around one of their core products. Working in tech you understand what a Beta really means and you can make that call on an informed basis but that's not true of a typical G-mail user today.
Lazy or evil, pick one.
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.
remember that Microsoft wasn't sued out of the blue. competitor companies lobbied for it. if Google lobbies first they should be fine.
My guess at the cause would be an CSP implementation difference.
Unless people want to get syndicalist/cooperative with their email, they'll go with the large free email providers.
(I have been my own SMTP server (hosted by OVH) for a few months now. I was blocked exactly once, by custom filtering from a small provider where the delivery status notification said to appeal to abuse@, I emailed them and they fixed it in minutes.)
What will happen? More people will block small providers because fewer exists? The issue is much larger than that. There need to be better ways to deal with email than just dropping it for arbitrary reasons.
> I was blocked exactly once
... that you know of
I've worked for companies where our internal mail servers just couldn't email some people; we presume their ISP black listed us and never published it on a shared list. (We only know this because people would call because they never got the email with the link to their purchased item.)
I do not have the time to worry about if every email I send will get delivered. Many systems don't send you a status notification; they just accept and then drop the message, meaning you may not see an error in the logs. You may not show up on public black lists for days. That's not something I want to be sinking my time into. I'd rather pay someone to run a well-known service that is very unlikely to have delivery issues.
(From my experience, I have never witnessed a situation where an email I had sent to someone had silently been ignored.)
http://serverfault.com/questions/364132/postfix-says-mail-se...
(Also, the mail was sent from www-data, which I think was an acceptable clue to classify the message as spam no matter from which server it came from.)
Obligatory links:
https://github.com/brong/cyrus-imapd/tree/fastmail http://jmap.io/
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?
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.
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.
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.
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.
> 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.
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.
A couple of points:
"Firstly there are competing platforms on which to deploy your programs."
I see the major web browser as those competing platforms. The effort to make something work on different web browsers is huge, almost, or equal to, the difficultly of choosing a cross platform development tool and targeting multiple OSes.
"...the first thing we'd do when we unboxed a mac or a PC was download and install facebook".
A native facebook application might be pretty cool. Really, do I do something much different when I use Thunderbird and eschew Gmail?
And native apps are good for things like Microsoft Office or things you expect to use offline and frequently. But if you make me download an app for Facebook or gmail and get me to update it every now and then, I will get pretty annoyed.
I also believe that there should be at least a strong mobile offering with any web application now-a-days. That said, here's my thought on the matter.
UI sucks for everything. It really seems to have always sucked and probably will continue to suck. Swing is a pain to develop. WinForms too. I assume from looking at Cocoa code, so is Apple.
I've been working on a Pomodoro app during this whole time. Just getting lists to work efficiently in Android is a bitch. You have to serialize objects in and out of view items to make sure scrolling doesn't absolutely crap out when you've got a lot of items. Even with Swift, the same is fundamentally true in iOS.
Making a native app that looks 1) unique and 2) nice is terrible. You have to have a team with a designer and developer. Anything less and you're going to be out of the market longer. Making a native app that meets the two criteria above on multiple platforms is incredibly time consuming.
So I've now decided to use Ionic + Angularjs + Cordova. I've been on that platform for 2 weeks now. In that time, I've learned Web SQL, Angularjs, Ionic and enough Cordova to get plugins installed. I am also further along than I ever was in my Android development. It even looks pretty using the default Ionic styling (I got a free UI team by using their stuff).
So even if I accept your speculation that apps will dominate the world. I assume it will be developed on an HTML5 or HTML* stack. That does require "interoperable universal interaction standards".
I'll continue this speculation to say that I think the appearance of apps will merge. There is little reason to have a brand for Android and a brand for iOS and a brand for Tizen, etc. Ionic apps look like Ionic apps without having to spend a lot of GUI logic saying stupid things like, If Android, put the tabs on the top. Again, you need a common standard for this type of design and that is HTML.
P.S. I know that games will suck in JS in the browser view. I know that JS has some serious issues with performance that will probably not be overcome for sometime. I've seen that analysis blog post too. But for CRUD apps like the Pomodoro or Foursquare or LinkedIn, Ionic and its ilk are perfect. The reason is, to beat the horse, is because of advancing open, compliant standards. CSS animations can now be hardware accelerated. JS performance is constantly improving (even if it is a horrible, horrible language).HTML is being banged out to house newer features. This isn't a polemic about how native has no values. It's a polemic against the idea that CRUD apps should have gone native.
I prefer web apps to native apps. Day to day, at work, our CRM, bug/issue/project tracker, document management, help-desk software, phone system management, knowledge base, email, document/spreadsheet software are all web-based. Historically, those were all native 'programs' (as late as mid 2000s) and they were all crap.
>All for something that could have been created as a native app much easier.
I don't know about that. Some things are easier with html/css/js than with a native framework, but it's not just about developer comfort. Web applications provide huge benefits to users over native apps - that's why we're willing to deal with the development stack (which is getting better every year).
>Imagine the man hours and effort that went into building Gmail.
It's probably not that bad. Writing maintainable web code isn't that hard these days.
>There's a lot of reasons that people have gravitated towards apps on phones
Yes. It all really boils down to performance. If you could get 60fps with a web-app on mobile (which in principle you should achieve), I don't think users would care. You'd also see an even bigger uptake of webview-based 'native' apps (a la phone gap).
That's harsh.
In this case, the business priority was a release coincident with Lollipop.
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.
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.
None of those things happend with Inbox. There were no bug reports filed, no mention of issues getting it to work, nothing.
So this was a pure business decision to not put any particular effort into making Inbox work in Firefox.
Now you might say that simply writing to standards should make it work in Firefox and if it doesn't that's a problem with Firefox, and I agree. But in my experience "writing to standards" doesn't really describe Google properties very well, especially when they try to push the envelope where standards don't exist yet.
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.
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?
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.
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.
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.
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.
Never assume malice when there is a perfectly reasonable explanation. They shipped an awesome product as fast as they could. Firefox support is probably coming soon.
A technical explanation? You mean like Google disabling security checks on their own domains, violating internet-standards?
Well yes certainly that would be a problem, unless they also controlled a majority-share browser.
Oh wait. Does this sounds like Microsoft of the 90s yet?
In their book, 'How Google works' they claim to settle with more what's best the user than their customer. That's such a bold claim when you are a monopoly.
Microsoft has done it, and got busted. Apple has done it, and got busted (albeit in a fairly small way). People are I think rightfully worried that the same thing could happen with Google. Even more so because of how respected they are with the hacker community and the tech community at large.
It's not about how they got their first monopoly, it's about how they got every one after that and what they do with them that matters.
A Mozilla JS dev fixed the sparse array bug the SAME DAY it was filed. Note that the bug wasn't filed until somebody saw a Google dev here on HN stating that the sparse array bug was the reason why Firefox couldn't work with Inbox.
Just because you have the resources to do something doesn't make it a wise use of resources.
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.
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.
They are?
They didn't even take the first step to solving it, which is filing a bug about it with Mozilla. When they mentioned the problem on HN, a Mozilla developer filed the bug for them and fixed it within a few hours.
So had they been _working_ to solve it, it would have been solved long ago. Like within days of them encountering it (adding some extra time to pin down the problem, which they _did_ do before not bothering to tell anyone about it).
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.
http://www.otsukare.info/2014/10/28/google-webcompatibility-...
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.
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?
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
"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.
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.
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.
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.