Alon Zakai (:azakai) Reporter
	Description • 14 years ago

In bug 594771 we implemented a simple hack for this. But we should fix it in a more proper way and remove that hack. See discussion in that bug for the background.

	Boris Zbarsky [:bzbarsky]
	Comment 1 • 14 years ago

What does "properly" mean here?  That is, what are you proposing we implement?  ;)

	Alon Zakai (:azakai) Reporter
	Comment 2 • 14 years ago

To elaborate, I meant to remove the hack and solve it in a nicer way:

1. A proper interface, without the mNewRequestsWillNeedAnimationReset variable.
2. Might make sense to wait until after bug 625245 (do not track images not yet bound to a tree), and/or the idea mentioned in the previous bug, of having several types of animation consumers. This issue might be simpler after them.

	Boris Zbarsky [:bzbarsky]
	Comment 3 • 14 years ago

> 1. A proper interface, without the mNewRequestsWillNeedAnimationReset variable.

So just add a boolean argument to nsImageLoadingContent::LoadImage?

Do we have a bug on having different types of animation consumers?

	Alon Zakai (:azakai) Reporter
	Comment 4 • 14 years ago

(In reply to comment #3)
> > 1. A proper interface, without the mNewRequestsWillNeedAnimationReset variable.
> 
> So just add a boolean argument to nsImageLoadingContent::LoadImage?
> 

That's good, but I think saving 'whether we need to reset the animation for a request' (as we now do) is a little odd. So I was hoping to find a better way.

> Do we have a bug on having different types of animation consumers?

It might make sense to do this as part of bug 625245 actually. I'll comment there.

	Joe Drew (not getting mail)
	Comment 5 • 13 years ago

Yep, this still applies.