330 bytes, text/html
2.90 KB, text/html
446 bytes, application/x-zip-compressed
143 bytes, text/plain
138 bytes, text/plain
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.
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.
*** Bug 53022 has been marked as a duplicate of this bug. ***
If the above URL is in your cache, it won't blink. Hit reload to see the show.
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.
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
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.
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.
*** Bug 57122 has been marked as a duplicate of this bug. ***
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>
*** Bug 56015 has been marked as a duplicate of this bug. ***
*** Bug 57271 has been marked as a duplicate of this bug. ***
I see this at the original url today (http://www-focus.fnal.gov/).
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.
Adding mlk (memory leak) keyword based on dup bug 56015.
*** Bug 58330 has been marked as a duplicate of this bug. ***
*** Bug 58645 has been marked as a duplicate of this bug. ***
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.
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).
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 :)
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.
This bug is probably causing the problems at amihotornot.com (bug 58963).
Set milestone to mozilla0.9
Adding self to cc, causing trouble for my sites too.
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.
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.
*** Bug 65032 has been marked as a duplicate of this bug. ***
*** Bug 67733 has been marked as a duplicate of this bug. ***
*** Bug 60874 has been marked as a duplicate of this bug. ***
Very annoying. Also check out the bug 56548. I think they are dups.
Another URL where it occurs consistantly: http://bbspot.com/toys/slashtitle/index.html
*** Bug 69233 has been marked as a duplicate of this bug. ***
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.
*** Bug 65614 has been marked as a duplicate of this bug. ***
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.)
Cool, one of the testcases on bug 65614 doesn't use tables: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=22669
*** Bug 56548 has been marked as a duplicate of this bug. ***
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.
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.
I'm pretty sure bug 63750 is a dup of this bug, so copying perf and topperf from that bug.
Updated status whiteboard. CC'ing pavlov. Pav: Does the new imagelib fix this bug?
yes, this will be fixed.
Created attachment 27691 [details] url for _really_ blinking image (other images don't blink for me)
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 email@example.com, did you try the URL that I mentioned here on 2/21/00? (I still get shrinking images on this 2001031208 build...)
Probabely fixed by the fix to 69534... Please check.
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.
Throbber not stopping is prob bug 39310.
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?
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.
Resolving as fixed. remaining issues are covered by bug 39310
Marking verified in the April 10th build.