Closed Bug 69405 Opened 24 years ago Closed 15 years ago

Reanimator UI (menu to start animated GIF images)

Categories

(SeaMonkey :: UI Design, enhancement)

Product:
SeaMonkey
Component:
UI Design
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: akkzilla, Assigned: jag+mozilla)

References

Details

(Keywords: helpwanted, Whiteboard: [feature]) 

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.
Status: NEW → ASSIGNED
Keywords: helpwanted
Target Milestone: --- → Future
(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?
Priority: -- → P5
Whiteboard: [feature]
*** 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
Component: ImageLib → XP Apps
*** 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.
Depends on: 152756
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. ***
Blocks: 119597
*** 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
Summary: Reanimator UI → Reanimator UI (menu to reanimate gif images)
*** 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.
Summary: Reanimator UI (menu to reanimate gif images) → Reanimator UI (menu to start animated GIF images)
Product: Core → Mozilla Application Suite
Assignee: akkzilla → jag
Status: ASSIGNED → NEW
Priority: P5 → --
QA Contact: tpreston
Target Milestone: Future → ---
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
Status: NEW → UNCONFIRMED
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.
Status: UNCONFIRMED → NEW
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.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.