Now that you can turn off image animation (bug 17686), it would be really helpful to be able to turn animation back on just for one image or one page. The best UI would be to offer a context menu over the image itself, with an option "animate" or some such. However, the current image animation pref works by turning off animation on the docshell, and it's not at all clear how to make it different for different images within the same page. So a much easier goal is to turn image animation on just for the current docshell (perhaps in the View menu?)

I'm taking this bug for now, but I can't guarantee that I'll have time to work on it, so future/helpwanted. I'll try to find time at least for a quickie solution, though (I want it too). Also adding Blake: he's working on UI in the prefs pane for animation control (bug 64831), but he might also have thoughts on the best way to implement the more immediate UI.

(Just pointing out that I have the UI for 64831 working, but tor expressed interest in waiting until the "never" crasher is fixed).

Sorry, missed where you asked for UI suggestions. Hmm...I agree that if we ever get the ability to animate certain images, that should probably be in the context menu. I'm not sure where it belongs for turning it off for the current page. Since other things on the View menu (Use Stylesheet, Text Size) apply to the current page only, I suppose putting it there would be fine.

I think stopping animations in the current page should be done by choosing `View' > `Stop' (or pressing the `Stop' button) a second time, as in 4.x. I remember, several months ago, that this already worked -- even though the Stop button appeared to be disabled, clicking it still stopped the animations. (As an improvement over 4.x, the `Stop' icon could be overlaid in one corner with a miniature of the `Load Images' icon, to indicate that clicking `Stop' again would stop the animations.) As for an item in the context menu, I'm trying to find a place for it ...

perhaps the stop icon should indicate network traffic or page load in its first state?

*** Bug 83258 has been marked as a duplicate of this bug. ***

Will this bug allow for animated graphics that have stop animating to be reanimated? Or does it only reanimate an animated graphic after animation has been disabled?

remove self

*** Bug 144109 has been marked as a duplicate of this bug. ***

Instead of adding a context menu item for "restart animation" / "start animation", I think we should make View Image animate images from the start (bug 100909) and always animate images even if animation is disabled.

Jesse: I'd like to see that too. That would probably require a different bug, though, since the fix would be in a different place (detecting that case and not starting animation in the first place, rather than trying to stop it in an existing docshell from a user-initiated action). Please cc me if you file it.

That's a nice idea. Couldn't it also help to change the preference such that one can adjust the number of animations, so that instead of (never, once, forever) we have (never, some number, forever)? (It's a somewhat obvious idea, but I didn't find anything like that in Bugzilla.) I just don't like ani-GIFs to use lots of CPU while I am not at the computer, so for me a setting of 5 times would be OK...

*** Bug 156826 has been marked as a duplicate of this bug. ***

*** Bug 175509 has been marked as a duplicate of this bug. ***

*** Bug 198050 has been marked as a duplicate of this bug. ***

*** Bug 201912 has been marked as a duplicate of this bug. ***

*** Bug 207168 has been marked as a duplicate of this bug. ***

adding "(menu to reanimate gif images)" to the summary to make the bug easier to find

*** Bug 240786 has been marked as a duplicate of this bug. ***

I suggest that the summary should contain the word "animated" as this is the one used in the Preferences window.

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This would still be nice to have --> NEW. Maybe this could also be offered by an extension.

I don't think anyone can work on this for default code, but as you say, this could be perfect extension fodder. For the SeaMonkey code, I see it as WONTFIX though.