This is one of the first features a new GCE user is likely to use (if they're exploring the UI and haven't yet started using the CLI) - and it's broken out of the box. Amazing.
It's amateur hour over there when it comes to frontend development - it's not a web app where cross-platform/cross-browser testing takes place, it's a Chrome app.
Feature-chasing. Firefox compatibility is a feature that nets them something like 5% of potential users. When they crunch the numbers, that's fewer than the 3 to 5 corporations they can get into their scope of market if they add the table-stakes features those corps require to consider GCP.
And Google's take on it is that a FF user can always switch to Chrome, since Chrome runs on all OSs that support FF.
FF support is, in theory, part of the acceptance criteria for new development, but it's not on the blocking list so it's not really part of the acceptance criteria.
I don't if this true but I have realized whenever I try to access google apps in firefox they are slow and sometimes breakdown but when I try to do it in chrome they just work fine.
Like I was trying to submit some work using google classroom on firefox it wasn't letting me upload the work but when I did it in chrome it just worked well
The conspiracy theorist in me wants to believe that this is not incompetence, but sabotage. Everyone uses Google products; if they work fast in chrome and slow on firefox, people will blame Firefox, not Google. And therefore will eventually switch to Chrome.
It's not intentional sabotage; it's positive feedback loops.
Using Chrome, your tooling experience developing software at Google is, maybe, 1% faster. Some of that is core (TBH, FF's engine is old and creaky and webkit-derived browsers out-perform it on all kinds of metrics, though FF has significantly closed the gap). Some of it is that teams develop for Chrome first, because it's the first browser shortcut available. Plus, Chrome has all kinds of extensions built in-house at Google to make your life easier, and those have to be rewritten from scratch if someone wants them for FF also.
So now when you're doing UI development and testing it, your first testbed is always Chrome, because it's what you're using as a developer. So bugs always get seen first in Chrome, and only seen in FF if your team has acceptance testing requirements or you happen to have a team member who uses FF. So the gap widens: now using Chrome in Google is, maybe, a 5% better experience, because you're that much less likely to hit bugs the developing team hasn't hit yet. And th positive feedback loop continues.
The only way I'm aware of to stop this is to force teams to put half their engineers on using FF as their primary browser, and I've never seen a team willing to do so.
FF has die-hard supporters inside Google, but few are so die-hard they're willing to intentionally slow down their own development velocity by using a less-supported browser. Google's too competitive to incentivize that.
(Note: this applies to bugs that crop up between OS platforms also, because that happens---sometimes, the details of Chrome on MacOS surface a bug that never shows up on Linux. Some teams do require one engineer at least to use Mac, because the MacOS userbase is big enough that there's financial incentive to not break it. FF has like 5% market share; there's no such incentive there).
Because (a) most of them predate the standardization of WebExtensions and (b) that API still isn't standardized enough to make building against it as cheap as building a chrome specific extension.
https://github.com/webcompat/web-bugs/issues/61522