I think we might in fact have a different definition of "quickly", yes. I think we may also have different definitions of "entire product is hosed". If gmail

I think we might in fact have a different definition of "quickly", yes. I think we may also have different definitions of "entire product is hosed". If gmail is significantly worse to use (not "doesn't load", just "loads with obvious visual artefacts"), that's obviously enough to get people to change browsers, all else being equal. And just to be clear, there are certainly cases when things got fixed quickly. But "always" is really stretching it; this was the exception, not the norm. > regressions are to be expected in an environment where the extent of browser testing is a function of engineer interest rather than centrally mandated Sure. The problem is the environment and corporate policy, not individual engineers. They're just responding to incentives as best they can, and in my experience are generally quite helpful within the constraints of the system. > just that this sort of thing was not Firefox specific Indeed, I don't think it was. It was not-Chrome specific. Here's a thought experiment. Say someone at Google who did _not_ test in Chrome committed a change that degraded the visual experience of gmail in Chrome and it got shipped. How would fixing that be prioritized vs a similar visual degradation in Firefox or some other non-Chrome browser? Assuming there is no emergency push involved, if the fix was not ready by the next push cycle, would it just slide, or would the original commit get rolled back?