It's taken more like 21 months, as far as I can tell (the bug was first reported against 1.9a3, in March 2007).
Basically, the timeline breaks down as follows:
1) Bug reported in Firefox:General (wrong place for it, and apparently not
triaged much, sadly).
2) It takes 11 months for someone other than the reporter to comment on the bug.
3) It takes 3 months for someone who knows how the bug system works to see the
bug, confirm it and request blocking.
4) Almost immediately the bug is moved to Core:General (another wrong place,
and even worse-triaged than Firefox:General).
5) The next day it's decided that the bug isn't a blocker for the release.
It's moved into the Networking component, which is basically unowned (at the
time, of the three peers, one (the owner) was working on Google Chrome and
not reading bugmail, one had a non-Mozilla-related job and wasn't reading
bugmail much, and one had a PhD defence coming up in 2 weeks time and hadn't
been really dealing with bugmail for 6 months).
6) Nothing relevant happens for a month and a half until Adam Spain takes the
time to go through and figure out when the bug first appeared (something
anyone with time could have done, for what it's worth). At this point,
people figure out which change cased the problem and finally move the bug
to the correct component (imagelib). Sadly, at this point imagelib is not
so well-owned. The previous owner has moved on to other things, and the new
one hasn't gotten up to speed yet.
7) Two days later there is a guess as to how to fix the bug. Unfortunately, the
person doing the guessing (one of the network peers mentioned above) is in
the middle of moving from Chicago to Boston at the time and has a 7-month
backlog of bugmail due to the the PhD thing I mentioned.
8) A month later the bug is moved out of imagelib and to docshell of all
places, claiming that it's a bug in the bfcache, not in imagelib (this in
spite of a regression range blaming an imagelib change).
9) Another month and a half later, there's more information about what might
need to happen to fix this, but the commenter is still working through that
seven-month backlog and working on bugs that are considered higher priority
(see the "not blocking" determination earlier).
10) Another two weeks later a fix is finally attached to the bug.
11) 3 days later a patch that works for Firefox 3 is attached.
12) A week and a half later, the trunk patch gets reviewed and is checked in.
Approval is requested for the branch fix.
13) A month and a bit later, it's approved. The next day it's fixed on the
branch.
14) It's another month and a half until the next branch release at this point.
I have no idea why approval took so long, but the real lag time was in getting the bug to the attention of people who had both the knowledge and the time to do something with it, combined with the lack of active code ownership in the most-relevant modules (imagelib and network).
It's taken more like 21 months, as far as I can tell (the bug was first reported against 1.9a3, in March 2007).
Basically, the timeline breaks down as follows:
1) Bug reported in Firefox:General (wrong place for it, and apparently not
triaged much, sadly).
2) It takes 11 months for someone other than the reporter to comment on the bug.
3) It takes 3 months for someone who knows how the bug system works to see the
bug, confirm it and request blocking.
4) Almost immediately the bug is moved to Core:General (another wrong place,
and even worse-triaged than Firefox:General).
5) The next day it's decided that the bug isn't a blocker for the release.
It's moved into the Networking component, which is basically unowned (at the
time, of the three peers, one (the owner) was working on Google Chrome and
not reading bugmail, one had a non-Mozilla-related job and wasn't reading
bugmail much, and one had a PhD defence coming up in 2 weeks time and hadn't
been really dealing with bugmail for 6 months).
6) Nothing relevant happens for a month and a half until Adam Spain takes the
time to go through and figure out when the bug first appeared (something
anyone with time could have done, for what it's worth). At this point,
people figure out which change cased the problem and finally move the bug
to the correct component (imagelib). Sadly, at this point imagelib is not
so well-owned. The previous owner has moved on to other things, and the new
one hasn't gotten up to speed yet.
7) Two days later there is a guess as to how to fix the bug. Unfortunately, the
person doing the guessing (one of the network peers mentioned above) is in
the middle of moving from Chicago to Boston at the time and has a 7-month
backlog of bugmail due to the the PhD thing I mentioned.
8) A month later the bug is moved out of imagelib and to docshell of all
places, claiming that it's a bug in the bfcache, not in imagelib (this in
spite of a regression range blaming an imagelib change).
9) Another month and a half later, there's more information about what might
need to happen to fix this, but the commenter is still working through that
seven-month backlog and working on bugs that are considered higher priority
(see the "not blocking" determination earlier).
10) Another two weeks later a fix is finally attached to the bug.
11) 3 days later a patch that works for Firefox 3 is attached.
12) A week and a half later, the trunk patch gets reviewed and is checked in.
Approval is requested for the branch fix.
13) A month and a bit later, it's approved. The next day it's fixed on the
branch.
14) It's another month and a half until the next branch release at this point.
I have no idea why approval took so long, but the real lag time was in getting the bug to the attention of people who had both the knowledge and the time to do something with it, combined with the lack of active code ownership in the most-relevant modules (imagelib and network).