Last Comment Bug 21623 - Stop button should stop animations
: Stop button should stop animations
Status: VERIFIED WONTFIX
: helpwanted, regression
Product: Core
Classification: Components
Component: ImageLib (show other bugs)
: Trunk
: All All
: P2 normal with 16 votes (vote)
: Future
Assigned To: Nobody; OK to take it and work on it
:
: Milan Sreckovic [:milan]
Mentors:
: 21530 74828 85425 256062 348214 (view as bug list)
Depends on: 33810 70030
Blocks: 81552 119597 163708 256062
  Show dependency treegraph
 
Reported: 1999-12-13 14:41 PST by Akkana Peck
Modified: 2010-12-18 13:53 PST (History)
30 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Proposed patch (9.28 KB, patch)
2000-07-24 08:19 PDT, hacksaw
no flags Details | Diff | Splinter Review
Proposed patch 1.1--minor update to merge cleanly with warren's 07/24/2000 22:45 check-in (9.28 KB, patch)
2000-07-25 08:47 PDT, hacksaw
no flags Details | Diff | Splinter Review
patch, updated for current tree (14.64 KB, patch)
2000-08-29 16:53 PDT, Chris McAfee
no flags Details | Diff | Splinter Review

Description Akkana Peck 1999-12-13 14:41:35 PST
On every past Netscape release that has supported animated images, the Stop
button would stop the animations.  Mozilla doesn't do this, and a lot of people
are going to miss it; I'm proposing that we should make this happen for beta.
Comment 1 Michael Lowe 1999-12-14 09:41:59 PST
On past Windows releases the Stop button does not stop animations, but there is
a menu item "Stop Animations" under the view menu that does this.
Comment 2 Michael Lowe 1999-12-19 07:16:59 PST
*** Bug 21530 has been marked as a duplicate of this bug. ***
Comment 3 neeti 2000-01-24 10:48:03 PST
reassigning this to neeti
Comment 4 leger 2000-01-25 17:51:04 PST
Putting on the PDT- radar for beta1. Will not stop ship beat for this.
Comment 5 Jesse Ruderman 2000-02-26 20:48:58 PST
If the page is still loading, the first "stop" hit shouldn't stop the 
animations. If "stop" is hit again (now that the page isn't loading), 
animations should stop.
Comment 6 selmer (gone) 2000-03-15 12:47:00 PST
In current builds, the stop button isn't clickable even though animations are
still running.  I haven't checked Mozilla, but on prior releases it was
important to be able to stop animations because they would suck down CPU cycles
even when the window was minimized.


Comment 7 Eli Goldberg 2000-04-16 16:39:17 PDT
Nominating for beta 2 by request of Seth Arnold.
Comment 8 hacksaw 2000-05-09 13:06:30 PDT
If anyone could suggest what files I should be looking at to get started, I'd be

happy to take a stab at this.

Comment 9 Suresh Duddi (gone) 2000-05-10 15:02:48 PDT
Removing nsbeta2 nomination. We are not implementing this feature.
Comment 10 sarnold 2000-05-10 15:06:45 PDT
dp -- please clarify. Are you not implementing "nsbeta2", or not implementing
"Stop button should stop animations"? Please tell me it is the former. :)

Thanks.
Comment 11 Akkana Peck 2000-05-11 10:59:32 PDT
hacksaw: this bug depends on the backend bug 33810, which is also blocking an
editor bug that's marked as nsbeta2, so one or the other of those bugs will have
to get reevaluated.  If 33810 gets fixed, then this bug should become fairly
trivial, just wire up the stop button to call the imglib API.

Incidentally, this will be a blocker for many people as far as adopting the
browser -- I'm sure I'm not the only person who finds animations a huge
distraction that make it almost impossible to think until they're stopped, not
to mention the CPU hit (noticable even on my fairly fast machine).  So I'm
putting dogfood back in the keywords even though I know it's going to be
minused.
Comment 12 neeti 2000-05-11 11:13:15 PDT
Currently, the stop button becomes disabled as soon as it finishes loading a 
page. This bug requires that the stop button is enabled even after loading the 
page, when there is an animated gif on the page. This will involve work on the 
xpfe side too.
Comment 13 neeti 2000-05-11 11:15:13 PDT
Currently, the stop button becomes disabled as soon as it finishes loading a 
page. This bug requires that the stop button is enabled even after loading the 
page, when there is an animated gif on the page. This will involve work on the 
xpfe side too.
Comment 14 leger 2000-05-11 15:31:59 PDT
Putting on [dogfood-] radar for beta2.

Do you know code to be called to stop animations?  If it is minimal and low 
risk.  We might fix for beta2.  But would not hold for this bug.
Comment 15 neeti 2000-05-26 14:54:21 PDT
Reassign to pnunn.
Comment 16 hacksaw 2000-05-28 14:28:06 PDT
I volunteered earlier to work on this one, but having just made my first foray
into the tree this weekend, I'm afraid even this is over my head.

The only thing I did find that might be helpful is a fix-me line in <A
href=http://lxr.mozilla.org/seamonkey/source/docshell/base/nsDSWebProgressListener.cpp#101>docshell/base/nsDSWebProgressListener.cpp</A>
that suggests a good place to re-enable the Stop Button if animations are
present, but I have no idea how to go about getting at that data from there.

Incidentally, someone has added a working "stop" entry to the context-menu you
get by right-clicking on individual animations, so things are looking up.
Comment 17 Gagan 2000-05-30 11:25:37 PDT
Hmmm... I wonder if this is related to bug 39727. cc'ing rpotts.
Comment 18 pnunn 2000-06-01 15:53:20 PDT
Let me start by saying that, on windows atleast, if you click
on the stop button, even though it is not hilighted (hilit?),
(which should mean the stop button is disabled)
animations stop.

There are about 3 diverse ways we can indicate animations should 
not animate or animate through one loop and then stop.
1> Context menu: right click menu would have animation options for 
the image
2> Preferences: set once for the whole browser 'experience'.
3> Additional buttons on the chrome.

The mechanism to control animations exists. You can specify
by way of the nsPresContext (and/or nsImageFrame):
1> normal animation,
2> no animation (display only first frame)
3> loop only once animation

Bill, would you like to add something to the context menu?
Hyatt, what about another button?
And who is doing prefs these days?????

Bill, I'm reassigning to you so its on your radar.
-P
Comment 19 R.K.Aa. 2000-07-23 20:45:15 PDT
on linux too, animations stop with a click on "disabled" looking stop-button.
(2000-072113)
Comment 20 hacksaw 2000-07-24 08:19:58 PDT
Created attachment 11810 [details] [diff] [review]
Proposed patch
Comment 21 hacksaw 2000-07-24 08:35:33 PDT
I've just attached a much belated patch proposal which behaves for the most part
like Navigator/Communicator 4.xx did, ie. there's sometimes a delay in updating
the button after a page finishes loading, and it doesn't take advantage of any
of the new API features (I that pnunn's ideas for setting the
one-iteration/frame modes in pref's or with another button are the way to go for
that). 

It also fixes two minor (potential) bugs that were lurking in nsImageGroup.cpp.
As others mentioned, the stop-button works as expected regardless of whether
it's shaded, so this is now an entirely cosmetic issue.
Comment 22 Matthew Paul Thomas 2000-07-24 19:56:43 PDT
Nominating for nsbeta3, since we have a patch waiting.

> there's sometimes a delay in updating the button after a page finishes loading

Why? Can that be fixed? Is it because it behaves the same as 4.x on Mac did, 
where the Stop button was only re-enabled after the slowest animated image on the 
page had gone through one complete loop?
Comment 23 hacksaw 2000-07-24 20:47:42 PDT
>> there's sometimes a delay in updating the button after a page finishes
>>loading
>
>Why? Can that be fixed? Is it because it behaves the same as 4.x on Mac did, 
>where the Stop button was only re-enabled after the slowest animated image on
>the page had gone through one complete loop?

Basically, except I would think it's the fastest animation, since it relies on
the IL_STARTED_LOOPING image-group notification that gets sent whenever any
animation completes its first iteration.

The best way to fix it would be to get the imglib code to send a notification as
soon as the fact that an image is an animation is determined.  This could
significantly simplify the fix, since we could probably guarantee that it's
determined *during* a load, and then could use the standard "nsProgressListener"
mechanism to talk to the front-end instead of the gross hack I've used.

I've looked through some of the imglib code, but it seems there are
several ways for animation status to be determined, netscape's GIF
extentions, "multipart-MIME" images, the new MNG stuff, etc.  There
is an "IL_FRAME_COMPLETE" notification sent to image-request obsevers,
but that gets sent even for single-frame images.  I'll take another
look tomorrow, but I haven't had any luck with that so far.
Comment 24 hacksaw 2000-07-25 08:47:19 PDT
Created attachment 11885 [details] [diff] [review]
Proposed patch 1.1--minor update to merge cleanly with warren's 07/24/2000 22:45 check-in
Comment 25 hacksaw 2000-07-25 09:25:21 PDT
>I've looked through some of the imglib code, but it seems there are several
>ways for animation status to be determined, netscape's GIF extentions, ...

Sorry, I should clarify this.  What's been confusing is actually just in the
modules/libimg/gifcom/gif.cpp code.  I can't for the life of me figure out where
it decides for certain that it's dealing with an animation.  I'm fairly certain
that the place where it invokes the "ImgDCBHaveImageFrame()" callback is wrong,
since it gets sent even for non-animated images, but I'm not sure what to do
about it. :(
Comment 26 verah (gone) 2000-07-25 13:38:09 PDT
Nav triage team: [nsbeta3+] because Mcafee wants it.
Comment 27 Chris McAfee 2000-08-29 15:36:07 PDT
Talked with pnunn.
Comment 28 Chris McAfee 2000-08-29 16:53:40 PDT
Created attachment 13709 [details] [diff] [review]
patch, updated for current tree
Comment 29 Chris McAfee 2000-08-29 16:59:17 PDT
tried the patch, stop button disappeared for me once on mouseover, ?
I also didn't see any noticable difference compared to non-patch build.
Maybe someone can clarify how I could test what's going on here?
The nsbeta3+ part of this bug looks like it's working to me,
off nsbeta3+ list.  Argue your way back on the beta list if you disagree.
Comment 30 Chris McAfee 2000-08-29 17:00:49 PDT
earlier comment with pnunn got truncated, using mozilla (heh)
Looks like the stop button is stopping animations: after loading,
hitting stop button stops the animation.
Comment 31 matt 2000-09-07 18:25:42 PDT
if you hit stop the animated gif does stop.
Just the UI does not update.
beta minus since we do not have any update on the patch.
Comment 32 Chris McAfee 2000-10-04 14:45:17 PDT
better summary
Comment 33 Matthew Paul Thomas 2000-10-21 08:31:14 PDT
Taking QA. (Why are there still open bugs floating around with Eli as QA? The
person who replaced the person who used to be his manager, or the person who
used to be the manager of the person who used to be his manager, or ... or ...
or *somebody*, needs telling off.)

Build: 2000102008 trunk, Mac OS 9.0.
Steps to reproduce: Visit <http://salon.com/> and wait for it to load
completely. Click the disabled-looking Stop button.
What happens: All animations stop.

What should happen:
* While the page is loading, the Stop button looks like a stop sign, enabled.
  Clicking it stops the loading, but does not stop the animations which have
  been loaded so far (if any).
* When the page finishes loading (or has been stopped from loading), if there
  are any animations in progress, the Stop button takes on the appearance of a
  stop sign overlaid with representations of images (e.g. the triangle, circle,
  and square of `Load Images' fame), to make clear that it has a slightly
  different purpose from the usual one of stopping loading. Clicking it stops
  the animations, restores the button it to its original appearance, and then
  disables it.

I strongly suggest this particular problem get fixed before any tweaks are made
to the details of exactly when the UI is notified about animations existing on
the page or whatever. With this fixed, at least, it will be a lot easier to QA
any other bugs relating to stopping animations.
Comment 34 Gervase Markham [:gerv] 2001-03-02 16:30:39 PST
mcafee@netscape.com - is this patch still relevant? Is it worth checking in?

Gerv
Comment 35 sairuh (rarely reading bugmail) 2001-04-05 15:20:00 PDT
*** Bug 74828 has been marked as a duplicate of this bug. ***
Comment 36 sairuh (rarely reading bugmail) 2001-04-05 15:22:15 PDT
renominating...
Comment 37 Akkana Peck 2001-04-05 15:30:26 PDT
I suspect the recent regression is because libpr0n doesn't pay attention to the
pres context's animation state.  Pavlov has various bugs related to image
animation, though I didn't see one that explicitly covers the fact that the stop
button no longer works.  Agree with se's nomination -- we shouldn't ship with
this regression.
Comment 38 Matthew Cline 2001-04-19 18:06:53 PDT
*** Bug 76766 has been marked as a duplicate of this bug. ***
Comment 39 Viswanath Ramachandran 2001-04-30 15:31:00 PDT
nav triage: the severity of this problem does not earn it an nsCatFood+ 
designation. reassigning to Pavlov as this is likely to have to be fixed in 
Image Lib code before it can surfaced in the UI. 
Comment 40 Stuart Parmenter 2001-05-20 14:15:14 PDT
removing patch and review since the patches here are obsolete.
Comment 41 Andreas M. "Clarence" Schneider 2001-06-11 01:01:44 PDT
*** Bug 85133 has been marked as a duplicate of this bug. ***
Comment 42 R.K.Aa. 2001-06-12 10:06:03 PDT
*** Bug 85425 has been marked as a duplicate of this bug. ***
Comment 43 Jesse Ruderman 2001-06-12 12:34:26 PDT
The recent regression (pressing stop doesn't stop animations) is bug 70030.
Comment 44 Jason Kersey 2001-07-24 00:44:47 PDT
-> 0.9.4
Comment 45 Jim Song 2002-03-20 20:31:56 PST
Why not mark this bug duplicate of 70030?
Comment 46 rbs 2003-07-05 22:47:10 PDT
Not a dup, see comment 12.
Comment 47 Akkana Peck 2004-06-19 10:15:47 PDT
Jesse says the regression (that pressing stop does not stop animations) is
covered by bug 70030, but that bug is Product Camino and all the comments say it
applies only to Camino.  Resummarizing this bug back to the original purpose.
Comment 48 Alexey Chernyak 2005-03-28 06:51:42 PST
*** Bug 163708 has been marked as a duplicate of this bug. ***
Comment 49 Andrew Schultz 2006-08-12 22:26:45 PDT
*** Bug 348214 has been marked as a duplicate of this bug. ***
Comment 50 Andrew Hagen 2009-03-21 14:16:57 PDT
Does this bug report solely concern applets like Flash, or does it include animated GIFs as well?

Here is an animated GIF of a cat. 

http://farm4.static.flickr.com/3197/2852605918_85b6a44c08_o.gif

The Esc keyboard button stops the animation in current trunk builds. The "Stop" button on the toolbar is grayed out and does not work. The Esc button does not stop the animation of Flash applets. 

Is that sufficient to mark this bug as WFM?
Comment 51 Akkana Peck 2009-03-22 09:19:16 PDT
Andrew: if you read the comments, this bug has always applied to animated GIFs. Flash is a different issue (and there's a separate RFE on it somewhere).

Firefox folk might want to mark it WONTFIX but it's not WFM.
Comment 52 Frank Yan (:fryn) 2010-12-17 17:30:35 PST
*** Bug 256062 has been marked as a duplicate of this bug. ***
Comment 53 Frank Yan (:fryn) 2010-12-17 17:31:43 PST
We now disable the stop button when the page is done loading, so this is no longer valid.
Comment 54 Samuel Sidler (:ss) 2010-12-17 17:45:21 PST
Except, you could re-enable the stop button... How is this RFE INVALID? Maybe it's WONTFIX, but I'd let a module owner/peer make that call.
Comment 55 Joe Drew (not getting mail) 2010-12-18 13:44:17 PST
The stop button is unrelated to the status of animated images, and that's the way it's going to stay.
Comment 56 Samuel Sidler (:ss) 2010-12-18 13:53:19 PST
That's more like it.

Note You need to log in before you can comment on or make changes to this bug.