Closed Bug 199045 Opened 21 years ago Closed 21 years ago

Animated image rotates although "Animate images should loop ... [X] never" is marked

Categories

(Core :: Graphics: ImageLib, defect)

Product:
Core
Component:
Graphics: ImageLib
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: volker, Assigned: jdunn)

References

(
URL
)

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

patch v2
1.18 KB, patch
bzbarsky
: review+
bzbarsky
: superreview+
asa
: approval1.4b+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030323
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030323

The GIF banner http://www.klografx.net/qiv/banner.gif rotates although I marked
"Animate images should loop ... [X] never"

Reproducible: Always

Steps to Reproduce:
1. open URL
2. look 

Actual Results:  
image rotates

Expected Results:  
don't rotate

Message-ID: <3E7F4065.3090503@hfigge.myfqdn.de> reports
"Loops once" works as expected. "Never" is like "Loops once".
*** Bug 199043 has been marked as a duplicate of this bug. ***
wfm with win2k build 20030322
Component: Image: GFX → ImageLib
Qualifying reproducibility to "sometimes": After rebooting my Linux the banner
does not rotate any longer (i.e. it works as expected).
dup of bug 103166?
WFM LInux 2003032305 
There definitely is a regression here, having to do with how the image is loaded.

I noticed the same problem on http://www.chicon.nl/strd-img/new.gif .

Steps to reproduce:
- set looping to never in the configuration panel
- load the image in a new window, and then press shift-reload
- notice correct behaviour
- click the url bar and press enter to reload from cache
- notice the image looping (incorrect behaviour)

-> confirmed linux 2003032517

note that this is not the same as bug 103166 which is about images in certain
locations being animated (like in a table background). The images in this bug
rotate even if you load them in a separate window.
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 200459 has been marked as a duplicate of this bug. ***
hmmmm, I can't reproduce on linux or win2k using 1.4a release build (and other
random builds)
In the meantime I saw other sites with rotating images.  Until a few weks ago
the did not rotate with my "never" settings. But from about middle of march 2003
some images rotate sometimes. It's not reproducable (any longer).
Another site is http://www.heise.de/newsticker/. Here are several rotating
images.  Normally they won't rotate on my settings, but about once per day they do.

This appears to be a duplicate of bugs 200557 and 103166. This might
also affect bugs where image animation stops (bug 192631).
Depends on: 103166
*** Bug 200557 has been marked as a duplicate of this bug. ***
I also see this bug with Windows XP and Build 2003041416. Some GIFs that are
animated although I have activated "Animate images should loop ... [X] never":

resource:///res/samples/test10.html
http://www.n-tv.de/images/200212/3047132_ticker9.gif
http://www.greencofinancial.com/images/logo.gif (from Bug 200557)

The gearwheels in resource:///res/samples/test10.html strangely stop animating
after a few minutes.

This is a recent regression. Otherwise I would have noticed this before, because
I hate those distracting anim-GIFs. ;-)
Blocks: 119597
Keywords: regression
OS: Linux → All
Hardware: PC → All
So, I haven't seen any discussion of this bug being closed, but I haven't seen
it manifested in the 20030422 builds. Has a fix been checked in or another bug
squashed tha took this one with it?
For me this works fine again for all examples given in this bug and the dupes
except for resource:///res/samples/test10.html

Tested with build 2003042208 and Windows XP.
Interesting.  If I download gear1.gif and load it locally (file:) or 
put it on a website (http:), it honors the loop flag.  If I load it with
file: from the mozilla install site 
(file:///C:/Program%20Files/mozilla.org/moz_4_22/res/samples/gear1.gif)
it honors the loop flag
HOWEVER, if I load it via the res: (resource:///res/samples/gear1.gif)
it doesn't... 

very interesting!
Well, seems I spoke too soon. Some GIFs that used to animate no longer do, but
I've seen three others that continue to animate.
Another gif picture that still animates:

http://www.n-tv.de/shared/symbole/chataktuell.gif

Tested with a CVS-build ofrom today on Linux.
Using my own build from today on win2k and linux
http://www.n-tv.de/shared/symbole/chataktuell.gif
http://www.n-tv.de/images/200212/3047132_ticker9.gif
http://www.greencofinancial.com/images/logo.gif 
None of these loop if I say Loop Never on either machine.

Stefan, can you create a New Profile.  Select Loop Never in that
and retry with chataktuell.gif?  Thanks
http://www.n-tv.de/shared/symbole/chataktuell.gif doesn't animate anymore with a
CVS build from today on Linux. I'm using the same profile as when I wrote
comment #17 but it works now. Strange.
On CVS releast from 2003-03-26 rarely some images still rotate (here the top
banner from http://www.heise.de/newsticker/).  In my opinion there is some kind
of random in the problem and it does concern to all kinds of animated GIF's, not
just to special ones.
Surely enough people have confirmed this bug now?

It seems fairly obvious that it is a regression,
starting around mid March, i.e. after 1.3 release.

Shouldn't the 1.4 code be compared to the 1.3 code
or (at least if this is still dragging on nearing
the time of the 1.4 release!) just replace the
ImageLib component with the older, working version?!

(btw, the bug still occurs even when JS is disabled)

>just replace the
>ImageLib component with the older, working version?!

uh...
the idea is bad in general (because then other bugs would come back), and is not
even possible (APIs used by imagelib have changed)
This is a regression from bug 83774.  The problem is that SetAnimationMode must
be called explicitly by clients of libpr0n.  All well and good, but it's called
in nsImageFrame::OnStartContainer.  If the image is loading from cache as the
page is loaded, it can blow through all the notifications before the image frame
is constructed, so that nsImageFrame::OnStartContainer never gets called.
Possible solutions:

1)  Move the animation mode stuff down into libpr0n (I bet pav would love this;
    also see solution 2 and its problems).
2)  Move the animation mode setting to nsImageLoadingContent::OnStartContainer
    (note that this could be somewhat expensive since we can't just get the pref
    from the prescontext then... is the animation mode really per-presentation,
    or is it per document?  Or just global?).
3)  Add code in nsImageFrame::Init() to set the animation mode if the current
    request already has an image container.

Solution #3 is easiest in the short term; in the long term we need to decide
what the image animation stuff should really be doing and actually document it
so we don't have to guess anymore... ;)

I won't be able to get to this for a week at least, so if we want this for 1.4
(we do), could someone do it?  biesi?
Blocks: 83774
Comment on attachment 122412 [details] [diff] [review]
patch

Um... how about not relying on currentLoadStatus and just setting the animation
mode if we have a container?  A lot of time can pass between container creation
and the status becoming STATUS_LOAD_COMPLETE
Attachment #122412 - Flags: review?(bz-bugspam) → review-
Well, part of the reason was speed - testing a bit is faster than getting the
image container.

but sure, I'll make that change
Comment on attachment 122425 [details] [diff] [review]
patch v2

oh, hm, I see your point... if there was a partial load, my original patch
wouldn't have worked
Attachment #122425 - Flags: review?(bz-bugspam)
Comment on attachment 122425 [details] [diff] [review]
patch v2

s/complete image/image container/, maybe? It's not complete by any means....

The rest looks fine.
Attachment #122425 - Flags: superreview+
Attachment #122425 - Flags: review?(bz-bugspam)
Attachment #122425 - Flags: review+
Comment on attachment 122425 [details] [diff] [review]
patch v2

This patch makes the [x] never animate images preference work again reliably.
It would be nice to fix this for 1.4b, and the patch is quite small and not
very risky.

bz: err. I will s/complete//, that's a leftover from the older patch
Attachment #122425 - Flags: approval1.4b?
Comment on attachment 122425 [details] [diff] [review]
patch v2

a=asa (on behalf of drivers) for checkin to 1.4b
Attachment #122425 - Flags: approval1.4b? → approval1.4b+
Checking in layout/html/base/src/nsImageFrame.cpp;
/cvsroot/mozilla/layout/html/base/src/nsImageFrame.cpp,v  <--  nsImageFrame.cpp
new revision: 1.279; previous revision: 1.278
done
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
*** Bug 204514 has been marked as a duplicate of this bug. ***
*** Bug 103166 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: