The article where the Mozilla guy complained said two weeks, but, yes. Months is possible. Maybe we have a different definition of quickly.
Disclosure: former Google employee, I did many pushes and fixed browser compatibility bugs whilst I was there.
In the timeframe we're talking about most products were on a biweekly push cycle. In the ideal case where there was no delay at all between you reporting a bug and it reaching the right person inside the company who could fix it, if that day happened to be on a branch cut day then that's a minimum of a two week delay to reach production unless the bug was so severe that the entire product was hosed for all Firefox users. Minor glitches in rarely used screens wouldn't count for a rollback or emergency push, for instance.
But sometimes pushes fail. There's a severe bug, attempts to fix it are too slow and the push window closes so the servers are rolled back. Now the latency is a month.
That's only software bugs. Now include the time taken for the bug report to be triaged, mis-directed, pinged, rerouted to the right person. Now include delays incurred if that person goes on holiday, gets sick or has other higher priority tasks, as bug handoff works about as well there as anyone else. That can easily add more time.
Finally, regressions are to be expected in an environment where the extent of browser testing is a function of engineer interest rather than centrally mandated. If they weren't testing Firefox well enough before they weren't testing it well enough after either. If Google had a central rule about which browsers had to be supported then I didn't know about it. There was just an assumption you'd try to support the browsers people used as best you could.
I'm not saying it was awesome or right, just that this sort of thing was not Firefox specific and there were plenty of IE or Safari compatibility bugs too.