Last Comment Bug 52798 - gif img in table with width=100% blinks rapidly (flashes, flickers) (can happen without tables) [layout]
: gif img in table with width=100% blinks rapidly (flashes, flickers) (can happ...
Status: VERIFIED FIXED
This is fixed by the new imagelib
: crash, mlk, perf, topperf
Product: Core Graveyard
Classification: Graveyard
Component: GFX (show other bugs)
: Trunk
: All All
: P3 normal with 2 votes (vote)
: mozilla0.9
Assigned To: dcone (gone)
: Chris Petersen
:
Mentors:
http://www-focus.fnal.gov
: 53022 56015 56548 57122 57271 58330 58645 60874 65032 65614 67733 69233 (view as bug list)
Depends on:
Blocks: 61477 71668
  Show dependency treegraph
 
Reported: 2000-09-15 09:24 PDT by Eric Vaandering (no email)
Modified: 2009-01-22 10:17 PST (History)
15 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
test case (may have to reload to see problem) (330 bytes, text/html)
2000-09-22 17:51 PDT, Jesse Ruderman
no flags Details
A sampling of the problem. Missing image in TD. (2.90 KB, text/html)
2000-10-04 15:52 PDT, Chris Petersen
no flags Details
zipped testcase (html + gif) (446 bytes, application/x-zip-compressed)
2000-10-21 09:22 PDT, Oliver Klee
no flags Details
URL of further test case: does not depend on width=100% (143 bytes, text/plain)
2000-11-29 02:19 PST, Chris Johnson
no flags Details
url for _really_ blinking image (other images don't blink for me) (138 bytes, text/plain)
2001-03-14 06:50 PST, Piotr Krukowiecki
no flags Details

Description Eric Vaandering (no email) 2000-09-15 09:24:45 PDT
On a fresh start, with this as my home page, the "rainbow lines" blink
erratically (but all at the same time). Going to another page and then "back"
solves the problem.

Build: 2000091506. Did not occur with 2000090808.
Comment 1 Jeffrey Baker 2000-09-15 09:41:56 PDT
I'm seeing this on Linux 2000-09-15-06.  See also http://news.gnome.org at the
bottom of the page.  The horizontal line (which is actually a scaled GIF) blinks
continuously.  In debug builds, this asserts continuously but my debug build is
horked right now so I can't remember the assertion.
Comment 2 WD 2000-09-18 06:39:09 PDT
*** Bug 53022 has been marked as a duplicate of this bug. ***
Comment 3 WD 2000-09-18 06:43:56 PDT
If the above URL is in your cache, it won't blink.    Hit reload to see the show.
Comment 4 Kevin McCluskey (gone) 2000-09-22 15:36:28 PDT
I am seeing the problem at http://news.gnome.org, but not at
http://www-focus.fnal.gov (I think the page has changed and there aren't any
animated gif's on it anymore.)

Reassigning to dcone.
Comment 5 Eric Vaandering (no email) 2000-09-22 15:46:55 PDT
Correct in that http://www-focus.fnal.gov/ isn't blinking anymore (I'm now using
build 2000092008), but the page has not changed. There never were animated gifs
on the site. The problem was alleged to be with scaled gifs. These gifs are
still scaled.

I too am still seeing the problem at http://news.gnome.org 
Comment 6 Jesse Ruderman 2000-09-22 17:51:36 PDT
Created attachment 15369 [details]
test case (may have to reload to see problem)
Comment 7 Jesse Ruderman 2000-09-22 18:02:34 PDT
Nothing will happen the first time you load the testcase or the Gnotices page.  
If you hit reload, the image will flash a few times and then collapse (on the 
original gnome page) or expand (on the testcase).  I think what's happening in 
each case is that it's getting replaced by alt text, which melts into the other 
stuff on the "gnotices" page but causes the table to expand in the testcase.  
After playing with the page for a while, Mozilla may just let it keep flashing 
forever (this happened twice while I was simplifying), but restarting Mozilla 
will return the page to its "normal" behavior of making it flash a few times 
and then implode.

Note that the testcase requires having a background image.  I think the 
background image and the width=100% image might be fighting over who gets to 
display.  Bug 49222 *might* explain why pressing escape makes it stop flashing 
when you press escape.
Comment 8 Chris Petersen 2000-10-04 15:50:27 PDT
Ok, I see this on another site (www.avis.com). The top td of table conatins a 
image assigned a width="100%". This image will flash when reload or disappear 
completely. Changing width to pixels will solve the problem.
Comment 9 Chris Petersen 2000-10-04 15:52:13 PDT
Created attachment 16162 [details]
A sampling of the problem. Missing image in TD.
Comment 10 Loco 2000-10-20 16:19:25 PDT
*** Bug 57122 has been marked as a duplicate of this bug. ***
Comment 11 Oliver Klee 2000-10-21 09:18:42 PDT
I will attach another testcase. Unzip the file (HTML + GIF) to your local hard
disk, load the HTML file and reload it. The image in the tabel will flash rapidly.

The source code (body):

<BODY>
  <TABLE border=1>
    <TR>
      <TD>
        thisisaratherlongword
      </TD>
    </TR>
    <TR>
      <TD>
        <IMG src="vrr_strich.gif" width="100%" height="3">
      </TD>
    </TR>
  </TABLE>
Comment 12 Oliver Klee 2000-10-21 09:22:00 PDT
Created attachment 17718 [details]
zipped testcase (html + gif)
Comment 13 Jesse Ruderman 2000-10-21 12:22:04 PDT
*** Bug 56015 has been marked as a duplicate of this bug. ***
Comment 14 James Lariviere 2000-10-21 15:10:58 PDT
*** Bug 57271 has been marked as a duplicate of this bug. ***
Comment 15 Jesse Ruderman 2000-10-21 16:08:53 PDT
I see this at the original url today (http://www-focus.fnal.gov/).
Comment 16 Jason Eager 2000-10-24 19:56:26 PDT
Adding "Mostfreq" keyword and "crash" keyword because many users of mozilla have
complained to me about it, and the browser ends up freezing on these pages with
flickering lines if I don't stop the line from flickering in time.
Comment 17 Jesse Ruderman 2000-10-24 21:56:46 PDT
Adding mlk (memory leak) keyword based on dup bug 56015.
Comment 18 Stephen Walker 2000-10-28 12:15:58 PDT
*** Bug 58330 has been marked as a duplicate of this bug. ***
Comment 19 Jesse Ruderman 2000-11-04 18:28:56 PST
*** Bug 58645 has been marked as a duplicate of this bug. ***
Comment 20 Jesse Ruderman 2000-11-04 18:36:31 PST
This happens even in a window with no status bar, so the problem isn't an 
interaction between the progress bar and the page.  For example, load 

javascript:void(window.open("http://slashdot.org/comments.pl?
sid=00/10/30/2259230&cid=21&light=0","","resizable=yes,scrollbars=yes"))

(scroll down to bottom, hit Ctlr-R)
Comment 21 R.K.Aa. 2000-11-10 16:19:50 PST
Is it certain that width=100% is an ingredience of this bug?
http://www.nor.no
There's a horisontal gif scaled to 98% there.
On occation it behaves eratically and vanishes on reload.
If i go there with PSM installed, and click the button to enter the bank
services at the site, behaviour can get real weird.
The gif goes into some reload loop, and for each loop a new PSM thread seems to
be spawned. Don't know who's the chicken or egg in that bug, but it kept
flickering and i had 60 PSM processes hanging in no time.
Again: I just want a confirmation that the assumption about 100% width is
correct here, in which case i'm observing another bug.
Comment 22 Jesse Ruderman 2000-11-10 18:37:25 PST
rkaa: I'm pretty sure it's the same bug, because you have to reload to trigger 
it, and it flickers in the same way.  I'd leave the width=100% in the summary, 
though, because it's a useful way to keep track of infinite reflow bugs and 
other bugs that happen when large % widths confuse layout.

Can you file another bug on the extra psm processes?  That sounds like a 
serious memory leak, and it seems likely that it could be triggered by other 
infinite reflow bugs (or maybe even dom actions).
Comment 23 R.K.Aa. 2000-11-10 19:10:02 PST
Already filed an exquisite PSM horror-bug (56366). Just trying to figure out
what else haunts it, since some of the bad behaviour obviously origin in mozilla
bits, not psm. I guess someone (if they tried) could split out a handful
assorted bugs from 56366. Glad to see this is one of them :)
Comment 24 Jason Eager 2000-11-12 16:02:02 PST
Adding to mozilla 0.9 radar. It doesn't appear in as many places as it used to,
but when it does, it will ALWAYS cause a crash over time.
Comment 25 Jesse Ruderman 2000-11-18 14:49:08 PST
This bug is probably causing the problems at amihotornot.com (bug 58963).
Comment 26 Chris Johnson 2000-11-29 02:19:38 PST
Created attachment 19865 [details]
URL of further test case: does not depend on width=100%
Comment 27 Kevin McCluskey (gone) 2000-12-20 15:02:23 PST
Set milestone to mozilla0.9
Comment 28 James Green 2001-01-03 02:44:46 PST
Adding self to cc, causing trouble for my sites too.
Comment 29 bugz 2001-01-04 21:09:03 PST
reproduced images flashing with gif, jpeg, png; without background images or 
percentual sizes. Flashing occurs when images are resized by javascript to 
widths or heights with decimals, i.e. trying to set a height of 100.8 pixels. 
Guess the same could be happening in reflows with percentages, the numbers don't 
get rounded and something gets confused? Setting decimal sizes in img tag 
doesn't cause blinky behavior. Tested 0.6 and win32-talkback of 2001y01m04d.
http://www.pp.htv.fi/etolvane/tt/randomdata/index_blinkytest-v6.html
Comment 30 ruth@innocent.com 2001-01-26 04:24:32 PST
Not sure if someone's already mentioned this, but the images are being reloaded
here - at the very least that PNG is being decompressed by libpng over and over.
You can see that because the PNG is slightly b0rked (Photoshop bug) and libpng
complains to console "Incomplete compressed datastream in iCCP chunk".
Presumably the GIF and JPEG are being reloaded too. I can't tell if they're
fetched from the network or just from cache.
I hope this information makes it easier to figure out what's actually wrong.
Comment 31 Eric Vaandering (no email) 2001-01-26 06:31:34 PST
Yes, I noticed on the original page (www-focus.fnal.gov) that it was reloading
from the network because it was generating lots of network traffic.

I don't know if this was the case earlier.
Comment 32 Grant Kwok 2001-02-04 15:39:47 PST
*** Bug 65032 has been marked as a duplicate of this bug. ***
Comment 33 R.K.Aa. 2001-02-05 17:15:54 PST
*** Bug 67733 has been marked as a duplicate of this bug. ***
Comment 34 Mike Palczewski 2001-02-06 09:59:57 PST
*** Bug 60874 has been marked as a duplicate of this bug. ***
Comment 35 Jure Repinc (JLP) 2001-02-07 10:47:24 PST
Very annoying.
Also check out the bug 56548. I think they are dups.
Comment 36 unapersson 2001-02-08 01:22:04 PST
Another URL where it occurs consistantly:
http://bbspot.com/toys/slashtitle/index.html
Comment 37 Stephen Walker 2001-02-17 15:24:20 PST
*** Bug 69233 has been marked as a duplicate of this bug. ***
Comment 38 HJ 2001-02-18 11:10:03 PST
I belief that bug 65614 is a dup of this one. I found that if you set <table
width="95%"> (or any other value) then the flashing and reloads for those images
will stop. Also note that mozilla keep recalculating the image size if % width
is used. There are at least two functions in the source doing this kind of
calculation for HTMLElements one of those two must be the cause for this pain.
Comment 39 Stephan Niemz 2001-02-18 12:59:48 PST
*** Bug 65614 has been marked as a duplicate of this bug. ***
Comment 40 Deven Corzine 2001-02-21 08:03:00 PST
I understand that bug 65614 was more recent, so it got marked as a duplicate. 
However, I think the summary on that bug is more accurate; can we replace this
summary with that one?

Also, note that this seems to be a reflow loop -- something involved in scaling
images by percentage (not by pixels) triggers a reflow, which re-scales the
images, which triggers a reflow, which re-scales the images, which triggers a
reflow...

As I commented in bug 65614, the following webpage demonstrates this clearly;
scroll halfway down the page and watch the multiple scaled-by-percentage images
flicker and shrink repeatedly:

http://www.nichia.co.jp/lamp-e.htm

Interestingly, it DOES eventually stop reflowing, after dozens (hundreds?) of
reflows...  (I don't know if this has any significance.)
Comment 41 Jesse Ruderman 2001-02-21 09:32:54 PST
Cool, one of the testcases on bug 65614 doesn't use tables:
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=22669
Comment 42 John Morrison 2001-02-21 19:16:50 PST
*** Bug 56548 has been marked as a duplicate of this bug. ***
Comment 43 Marc Attinasi 2001-02-22 17:36:02 PST
I wonder if this is caused by bug 69534?  I hope so, because I have a fix for
it. Basically, GIFs are causing reflows for every pane of the animation (for
some reason, even non-animated GIFs cause repeated reflows). I simply avoid the
reflows if the image size is fixed since any changes in the image size are
irrelevant.
Comment 44 Jesse Ruderman 2001-02-22 18:49:39 PST
Most of the testcases in this bug don't involve animated images... 

Even if that fix takes care of all the testcases in this bug, we should still 
make sure that a reflow caused by some other change on the page wouldn't cause 
an image to be reloaded from the server.
Comment 45 Jesse Ruderman 2001-02-22 18:55:50 PST
I'm pretty sure bug 63750 is a dup of this bug, so copying perf and topperf 
from that bug.
Comment 46 Kevin McCluskey (gone) 2001-02-28 10:29:56 PST
Updated status whiteboard.

CC'ing pavlov.
Pav: Does the new imagelib fix this bug?
Comment 47 Stuart Parmenter 2001-03-02 13:58:03 PST
yes, this will be fixed.
Comment 48 Kevin McCluskey (gone) 2001-03-05 14:21:09 PST
Updated status
Comment 49 Piotr Krukowiecki 2001-03-14 06:50:12 PST
Created attachment 27691 [details]
url for _really_ blinking image (other images don't blink for me)
Comment 50 Deven Corzine 2001-03-14 08:23:25 PST
That's weird.  The image itself blinks!  Is this a GIF animation problem for
this example?

     http://ksi.ii.uj.edu.pl/images/instytut.gif

piotr@pingu.ii.uj.edu.pl, did you try the URL that I mentioned here on 2/21/00?
 (I still get shrinking images on this 2001031208 build...)
Comment 51 Marc Attinasi 2001-03-14 12:09:05 PST
Probabely fixed by the fix to 69534... Please check.
Comment 52 R.K.Aa. 2001-03-18 02:12:37 PST
tested http://www.nor.no and http://news.gnome.org/gnome-news w/ linux build
from 0317. I used to see the "flashing lines" and they no longer flash now.

Some kind of problem seems to remain though:
Those pages don't finish loading untill a timeout seemingly triggers after
nearly 3 minutes. (Throbber keeps throbbing etc. but there is no network traffic.)
This final timeout happens when socket enter TIME_WAIT state. First then does
the throbber stop / progress-meter reset.
Comment 53 Eric Vaandering (no email) 2001-03-18 06:13:10 PST
Throbber not stopping is prob bug 39310.
Comment 54 R.K.Aa. 2001-03-18 07:05:06 PST
I tested more of the sites that are dups/testcases of this bug:
*ALL* of them now show the same behaviour: throbber and progress-meter doesn't
reset til some timeout occurs. This at worst means 3 minutes of idle waiting, to
see if something more "happens to load". Totally unacceptable.
Take a look at the minimal testcase in this bug for instance:
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=15369

What happens in these cases is that the TCP socket remains in state ESTABLISHED
for far too long. Why doesn't it go TIME_WAIT or even close when the page has
loaded?
Comment 55 ruth@innocent.com 2001-03-19 08:55:06 PST
Sockets remaining open isn't necessarily a bug (HTTP/1.1 performance benefits
come in part from not doing too many SYN/SYN|ACK/ACK dances with the same
server, and sockets might be staying open to handle that)

Throbber not stopping is one of the children of bug 39310. Look there.
Comment 56 Kevin McCluskey (gone) 2001-03-26 17:20:31 PST
Resolving as fixed.
remaining issues are covered by bug 39310
Comment 57 Chris Petersen 2001-04-10 16:45:31 PDT
Marking verified in the April 10th build.

Note You need to log in before you can comment on or make changes to this bug.