We use two gifs for the throbber, a static one for when the browser isn't busy and an animated gif for when it is. The static gif displays fine, no problems. When you go to a webpage, we switch over to the animated gif. However, it takes a long time to image and a blank square is drawn in its place. If the page loads quickly enough, you never even get to see the animated gif finish imaging once and so the throbber appears and disappears as you surf. For long pages, there is enough time to render the animated gif so you see it. This is all platforms, but linux is affected the most. It seems to take the longest to render there so you almost never get to see it animating. Nothing is "broken" per se, it just looks bad. really bad.

Re-assigned to dp@netscape.com. dp, this looks like a netlib or imagelib issue.

Looks bad is ok for M5. This does not effect functionality.

this seems to be working ok on windows. can we get the other platforms rechecked and re-open as [PP] bug if linux or mac are still struggling to do the right thing...

clearing sar from list, replacing with cyeh (i guess) Whoa, whoa, whoa. Since when do we mark a bug as resolved when looks ok on Win32??? Sure, annotate that it looks ok on win32, but don't resolve it so that it drops off our radar! Shame on you. Reopening bug as macos does this still.

Marking as PP, clearing resolution.

Pam could you investigate this one.

?? Sounds to me like the problem is when the throbber image is requested, which is more of a chrome/widget thing than an image thing. The problem is not decoding the image, but when the image request is issued. The known Netlib/imagelib problem in which netlib checks with the server for the lastmodifieddate on the image could slow things down alittle. But this can't be addressed until Necko lands. I could mark this as a dupe of the bug I have for that problem. Pink, are you still unhappy with the display here? -pn

I didn't hear from anyone. marking worksforme. -pn

sorry, pam. reopening (i should have read that last report more carefully, but i don't think i ever saw it, maybe a mail burp). Since the throbber image is local, there isn't a server for the external requests. I just verified that it still does this on today's build 5/14/99. What do you mean about it being when the request is issued?

clearing resolution

adding sfraser and radha to the bug.

I'm pushing this out to M7. After a discussion with pinkerton, a very probable cause is that NU_CACHE has not landed for the Mac. Which would mean there is no cache for the mac. Which would be bad. -pnunn

adding gagan to the cc list. Gagan, is it true that the mac currently has no cache? If so, where is it on disk? Is it the old cache?

Another question: Are our fileopens slow? They were painfully slow initially. Could this still be an issue? -pn

*** Bug 1865 has been marked as a duplicate of this bug. ***

Eli, I'm basically migrating you over from bug 1865. This is all you buddy. Someone want to change the componet? I'm afraid to.

Status quo sounds fine to me; thanks!

[Note to self for verification: when verifying this bug, double-check that duplicate bug #1865 was fixed, too.]

Moving all Apprunner bugs past and present to Other component temporarily whilst don and I set correct component. Apprunner component will be deleted/retired shortly.

Could this be a dupe of #8645? -pn

I need necko to land to address this properly. -pn

*** Bug 10989 has been marked as a duplicate of this bug. ***

By the wisdom of leger@netscape.com, I append the following annotation: (MICROSOFT WINDOWS 98 1999080212 Apprunner build) As the start-up page is loaded (be it the MozillaZine default or a URL specified at the command-line), the throbber gapes blankly at the user, remaining static rather than animating. Oh: the original bug is no longer evident to mine eyes on the cited platform (having been all too visible), but was sealed *before* the rumble of Necko.

With the latest builds 1999080508 on Linux and Win32 and build 1999080510 on Mac, the throbber seems to be loading a lot better, even though you still see the blank square for a really short moment (a little longer on Linux).

*** This bug has been marked as a duplicate of 18738 ***

Rubber-stamping as duplicate. Leaving note in 18738 to verify this bug when 18738 is verified.

*** Bug 19436 has been marked as a duplicate of this bug. ***