Closed Bug 50778 Opened 25 years ago Closed 25 years ago

Throbber fails to fully animate during page loading

Categories

(Core :: Graphics: ImageLib, defect, P3)

Product:
Core
Component:
Graphics: ImageLib
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: minter, Assigned: pnunn)

References

Details

(Keywords: polish, Whiteboard: [dogfood-][nsbeta3+])

Using nightly build 2000082921 (and a couple days prior). When pages are loading, the "M" logo at the top-right doesn't animate. It does the first frame of animation and freezes while the page is loading. The status bar at the bottom-left works fine.
Duplicate of 50489
*** This bug has been marked as a duplicate of 50489 ***
Status: UNCONFIRMED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Why is this a duplicate of bug #50489? That bug was about wrong constants in js code, and that is indeed now fixed. This, however, is a completely different problem in that the throbber only manages to animate one frame. This problem also happens in Mozilla 083004 on NT4.
Well, if you're seeing it too, I should probably reopen it. :-)
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Summary: Mozilla "M" icon doesn't move during page loadings → Mozilla "M" icon (throbber) doesn't move during page loadings
Please clearly describe the symptoms you see in a build 2000-08-30 or later.
I see the throbber half-change, then stops. When the page loads, the initial state appears again. The throbber never fully animates. This occurs on 083004 Win98.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Summary: Mozilla "M" icon (throbber) doesn't move during page loadings → Throbber fails to fully animate during page loading
That is basically what I see, too. The throbber never gets past the first frame of its animation no matter how long it takes the page to load. Mozilla 083004 on NT4.
Ditto for 2000083008 on Linux/i686.
Right after the browser is started (and goes to mozilla.org) the throbber animates correct. All pages loaded after that, will show the behaviour as described in this bug.
Progress bar is not working freezes with throbber, and Will display document done while page is still loading, before the page is displayed. On Linux i686 083008
We have to have a working throbber for beta3.
Keywords: nsbeta3, polish
Some observations: 1. Setting the "busy" image in brand.css to a different static GIF causes that GIF to show up, so the CSS etc is working. 2. Changing the interframe delay in animthrob.gif doesn't help.
If I turn off imglib cacheing of chrome images, then the throbber starts working again. Over to pnunn.
Assignee: clayton → pnunn
I think what's happening here is that the code to cache chrome images isn't working well for animated GIFs. syd/pnunn, please take a look.
Component: Layout → ImageLib
Hardware: PC → All
Target Milestone: --- → M18
Keywords: dogfood
okey doke. -p
Status: NEW → ASSIGNED
Putting on [dogfood-] radar. Not critical to daily work.
Whiteboard: [dogfood-]
approving for beta3
Whiteboard: [dogfood-] → [dogfood-][nsbeta3+]
*** Bug 51643 has been marked as a duplicate of this bug. ***
on mac, the behavior is that the throbber _vanishes_ while it is "animating." A pretty neat trick, but not what we want.
on occation it completely vanish on linux also.
On NT4 2000-09-06-04 build with modern skin, I too see the "animated" throbber vanish. This is reproducible every time a page is loaded.
To me Linux nightly 2000090621 the throbber vanishes just every page loading too.
This is actually a dupe of #41268. Since the chrome is now in the image cache FOREVER, and since there is no mechanism to determine an animation is an animation until the 2nd frame appears, and since the imglib expects animations to reuse the image container for all of its frames, the throbber will not work until: 1. bug#41268 is fixed. 2. the throbber is temporarily put into single frame images as it is in viewer. 3. We turn off PIN_CHROME. If I mark this a dupe, I know I will get 10 million new bugs about the throbber not working. So I'm marking this bug as dependent on bug#41268, in the hopes people will realize the bug is known and not file yet another new bug. -p
Depends on: 41268
*** Bug 52067 has been marked as a duplicate of this bug. ***
*** Bug 52438 has been marked as a duplicate of this bug. ***
I'm adding this as a "mostfreq" because people are commenting about this (IRL, IRC, ICQ), but aren't filing bugs on it because they know it would be a dupe.
Keywords: mostfreq
I'm adding a "mostfreq" because people are commenting a lot on this bug on IRC, ICQ, etc, but they aren't filing bugs on it because they know it would be a dupe. Hopefully, this will raise the visibility of this bug so 41268 gets fixed.
I have checked in a hack to fix this until the imgcache can handle animations. There is already a bug to address the imgcache fix, #41268. -p
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Seems to be working now. Tested with the Sept 14th build (2000091420).
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.