The Safari icon on Safari error pages is squished. To reproduce: open Safari and go to <http://safaricantfindtheserver.com/>.
It looks like r36628 introduced a change that causes the current frame in the image to advance to 4. This in turn confuses the code in BitmapImage::draw, which uses the size of frame 4 (16x16) while the caller passes a 512x512 source rectangle, based on frame 0.
*** Bug 20944 has been marked as a duplicate of this bug. ***
I can't repro on Safari for Windows, which uses a PNG rather than an .icns. However, I think I have a fix for this anyway. r36628 is blameless here; it just allowed animated images to actually animate. The real bug was the earlier change of mine that made us think this was an animated image, because shouldAnimate() was checked before m_repetitionCount got set.
Created attachment 23582 [details]
I can't test that this actually fixes the bug, but I bet it will; please try it out.
The attempted fix here is to be more careful about getting/setting m_repetitionCount, similar to how we already do with other members that mirror members on m_source. Don't check it unless it's actually set.
I eliminated m_animatingImageType, since it was just equivalent to (m_repetitionCount == cAnimationNone) and thus unnecessary.
Instead of a simple bool m_haveRepetitionCount like the rest of the members on this class do I had to use a tristate enum m_repetitionCountStatus, to handle the way we recheck the repetition count at the end of decoding the image.
*** Bug 20936 has been marked as a duplicate of this bug. ***
The r36628 change was rolled out in r36702.
(In reply to comment #6)
> The r36628 change was rolled out in r36702.
So should this bug be resolved?
Closing, since the original patch that caused this regression has now been