Most of SaaS applications operate in this regime - they own user data, so they become "sticky" and non-substitutable very quickly. On the other hand, standardization of browser features makes browsers not very "sticky". This way, when a SaaS - any SaaS, not just Google's - works much better on Chrome than on Firefox, this drives adoption of Chrome by that much.

If it i make google docs great/dominate, then firefox, and safari are critical. You would ask hard questions and have deep discussions around dropping support for internet explorer. If someone suggested khtml (picking something old and poorly maintained) would work with just a little effort you would have a serious discussion around just how much effort that takes.

If the incentive is to make google great then things are different. Losing a few Firefox users might well be worth it if you can convert a few others from firefox to chrome. You might even go so far as to needlessly break firefox once in a while to drive your incentive.

I don't know how google is setup. I've seen companies setup both ways. There are downsides to both.

Google is an advertising company. The goal of every Google product is to provide the company with more data, to make users give the company more of their data so that data can be mined for more data.

Controlling the browser or OS means having the ultimate access to the users the ads will be shown to. So if a Google app doesn't help harvesting data, it must be used to push the OS or browser. Google allows for a lot of indirection but ultimately if a product neither harvests interesting data nor helps push users to using Google products that do, there's no reason to keep it around.

You can try and blame sales, you can try and blame “innovate or die” but also engineering always shares some blame too. Often it’s engineering who want to exploit shiny new tech or make new shiny thing and not do the inglorious work of maintenance and support.