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.firstname.lastname@example.org> 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).
*** 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. ;-)
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?
16 years ago
Attachment #122412 - Flags: review?(bz-bugspam)
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
Created attachment 122425 [details] [diff] [review] patch v2
Attachment #122412 - Attachment is obsolete: true
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
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.
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
Last Resolved: 16 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.