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