Closed Bug 151864 Opened 22 years ago Closed 22 years ago

Animated gif banners appear "black" after multiple reloads

Categories

(Camino Graveyard :: HTML Form Controls, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: chrispetersen, Assigned: sdagley)

References

()

Details

Attachments

(6 files)

Build: 2002-06-14-05
Platform: OS X 10.1.5
Expected Results: Animated gifs should appear correctly
What I got: Some of the page's animated gif images render as "black" objects.
Basically, they missing their content.

Steps to reproduce:

1) Go to aol.com
2) Reload the page multiple times (Place focus in url field and press return).
3) Some of the animated gifs appear as black colored object.
Attached image screen shot of aol.com
Three animate gifs appear as black colored objects after reloading page.
Hmm, I don't see this in 0.3, regression?
Status: NEW → ASSIGNED
Using the same steps provided, I can reproduce in 0.3.0 with my machine (Dual G4
800).
hmmm, still works for me. Do you see this anywhere else?
I can repro this.  0.3.0 06-14 build on OS 10.1.5.  
Chimera 0.30:

I also saw this very bug on the maccentral.macworld.com, but was not 
able to reproduce it.  It happened with the animated gif ads going down 
the right side of the main page.
Chris or Winnie, if this is a regression, can we figure out the builds it
appeared between? 
I "thought" this might be a regression so I tried with an older NB build
(2002-06-11-11). Based on the steps provided, I can reproduce it in this build
too. Of course, this occurs in 0.3.0 but haven't tried a 0.2.8 or earlier build.
Blocks: 147975
Hmmm... I'm having trouble reproducing this one.  I tried using several builds:
 07-18, 07-02, 06-18, and 06-14.  I have not been able to repro this even though
I said in comment 5 that I could repro with the 06-14 build.  

Petersen:  could you try reproducing this?  

If this becomes too intermittent, we might just take this off the blocker list
and mark it as WFM. 
I'm still able to reproduce it with today's build (2002-07-18-05). Usually, the
banner ads don't appear black upon first load of the page. I general see the
problem after reloading the page (using the original steps provided).
->sdagley for more investigation
Assignee: saari → sdagley
Status: ASSIGNED → NEW
Repeatedly reproducable in 0.4 under both 10.1.5 and 10.2
cc:'ed saari since it looks to be an imagelib bug
For some reason I just have not been able to reproduce this on my machine. Can
you try blowing away your cache and see if it still happens? I'm wondering if
this is a cache corruption/weird state issue.
Well by definition it should be cache related since it happens when the page is
reloaded and not on initial load.  It does _not_ happen every time however.  The
configurations I tested on were a dual-1G w/10.1.5 and a TiBook800 w/10.2 so you
may need a faster computer to repro.
Timing related perhaps?  Peterson was testing on a dual-800, I'm using a dual-1G
and a TiBook-800.  saari's TiBook I know is slower (TiBook-550?).  What's your test
system Winnie?
Component: Page Layout → HTML Form Controls
some debugging suggestions, make a simple test case that shows this behavior,
then in nsImageMac drawing routines start logging to see if we at least think
we're drawing the whole thing. For example if I see lines 0-10 and 25-60 but I'm
missing ones in the middle, then we have a updating issue. Maybe in the decoder,
although I doubt it, probably in layout invalidation/updating code. That is the
first thing to figure out. If we think we're drawing the whole image, then maybe
we have a cache issue, or a weird failure case we're not handling.
Ok, I'll work on a reduced test case for this page.
Attached file reduced test case
This test case uses two external JS files:

* A JS banner function that creates two iframes(gif images)dynamically
* Pop up JS function that executes on document load
Interesting, so the images by themselves don't exhibit this behavior, they need
to be in dynamic iframes?
Yes, at least from my research. Here is how I can reproduce with the testcase:

(First, try deleting cache before starting test)

1) Load test case
2) Two banner ads appear (correctly) on page.
3) Pop ad window opens. Close this JS created window.
4) Reload page and continue steps 2-3.
5) The banner ad on the page will turn "black" after multiple reloads.
I usually saw the problem occur after closing JS pop-up window and placing focus
in the browser window. The banner ad would turn "black".
Before we blame popups completely, I've seen the black images on aol.com w/o a
popup window being involved.  As for the simplified test case, I can't repro the
black image problem on my dual-1G system under Mac OS X 10.1.5 if I have popups
disabled.  With popups enabled I see it somewhat >50% of the time.
OK, I'm attaching a revised test case without the pop-up JS function. The
problem does occur after numerous reloads. Placing focus in url field and
pressing return seems to have a better chance of reproducing the problem at
least for me .
Damn, I attached the wrong test case (removed_pop_up). Attaching the real one
now.....
Keep placing focus in the URL field and continue to press the return key.
I couldn't reproduce this bug in Mozilla.  You ever manage to do that Chris?
No , I haven't seen this happen on a Mozilla build. However, I'll try with the
latest nightly to see if I can reproduce.
Chris Petersen, can I call on your testcase freation fu and ask for a test page
with images of different sizes?  Having two images exactly the same size makes
it kinda hard to distinguish which is which when all the obvious debug info you
have is the image dimensions :-)
Ok , I modified the HTML javascript.

first image is (240 x 120 px)
second image is (120 x 60 px)

Each iframe have red border as well.
I originally just planned to report this bug until I found it here already...
However... I don't use tabbed browsing a lot and often browse oldskool-style
with multiple windows open... "images suddenly going black" happens to me a lot
when I close a window and focus gets on another one... Images in this other one
go black one after the other once the focus hits the window...

Maybe this is better reproducable than hitting like crazy on the reload-button
until it maybe happens...

I also think this is a regression bug as I use Chimera from the very early
versions and it started happening somewhen, but not in a lot of the early
builds... too bad I can't remember exactly when this started...

Good luck...
I'm able to reproduce this problem on apple's site using the iSync animated gif.
Simply reloading the attached test case will cause the image turn "black".
A IMG element which references a animated gif image.
Reloading that attachment WorksForMe using Chimera/2002092304 on 10.1.5.
The bug exists when I am using the 20020928 build, but does not exists in
20020929 build. I am using OSX 10.2.1

I am wondering since no patch has been created in the Chimera branch (as viewed
in Bonsai Query), why is there a difference?
I'm seeing this with all kinds of animated gifs using Build ID: 2002100204. It's
not just with reloaded pages - I've seen this with fresh pages, too.
Yes, this is becoming more frequent in recent builds for me too. Steve, how are
we progessing on this issue ? Tested with the 2002-10-03-04 NB under 10.2.1.
I just saw this with 10/06, but it occurs the first time I load a page as well as on reloads 
(randomly). In fact not only does the apple page now have black on some animated gif's, 
but the switch person's head is not aligned??? If I clear the cache and history the 
problem happens the first time I access the page. Should I report it seperately since it 
doesn't seem to be on reload?
Petersen reported he hasn't seen this lately and I can't repro it anymore. 
Perhaps sfraser's drawing cleanup fixed the problem?  Marking FIXED on that
assumption and hoping nobody will prove me wrong.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Yes, I cannot reproduce this with any of the attached test cases. Have seen this
problem in awhile so I going to mark verified. If I see this happening, I will
reopen.
Status: RESOLVED → VERIFIED
No longer blocks: 147975
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: