There is "Current ranking: (|15)" (where "|" - arrow up or down). Loading it at first time causes this problem (see attach), reloading resolves the problem. See also every accaunt http://stats.distributed.net/csc/psummary.php3?id=196242

ezh@infonet.ee is refering to the fact that the arrow IMG is overlapping the '(' bracket upon initial load of the page (as is visible in the first attachment to this bug). This only happens the *first* time you visit the page -- likely due to timing with the cache and the fact that the IMG tag does not specify HEIGHT and WIDTH. Steps to reproduce: 1) Shut down Mozilla. Start Mozilla -- that is, the memory cache must be empty; if this bug is still OPEN when the disk cache is added to Mozilla, then, additionally, you will likely need to blow away the disk cache. 2) load either the reported URL, or better, the second attachment (to follow this note). 3) (if the bug is still active) notice that the arrow IMG overlaps the '(' Key Point: This appears to be a problem with painting -- if you simply hide mozilla with another window, and then reveal mozilla again, the 'overlap' is not present after the repaint. [Alternatively, scroll down, then back up, and the 'overlap' is gone.] Platform and build tested: 1999123008 Win95 (and ezh@infonet.ee on win98) Setting to pierre@netscape.com / Compositor (cause it seems to be a paint thing although it's very close to the where painting meets layout/reflow).

Oops -- meant beard / Compositor not pierre / Compositor

I'll also note that if you load this testcase + IMG over a fast pipe, you may not be able to reproduce this bug (that's my intuition, at least). On the other hand, you have to like it when the corner cases keep going further into the corners :-]

This must be a layout bug. No decisions about image placement are made in the compositor code.

[Waving my hands at this point, but I'm curious as to whether my understanding of the engine works.] Visually, loading the attachment (with a clean cache) suggests to me that, the HTML is layed out pending notification of the actual image dimensions; When the image is received, layout reflows the page, or at least requests a paint of the damaged region. It's at this point that either the reflow or the repaint is being dropped on the floor. [Again, just curious].

Actually it's just a painting problem. Cover the window and expose it and then it repaints fine. Thanks for the nice testcase. It makes it clear that the problem is we're not repainting properly once we get the width/height of the image (the width/height is not included in the HTML).

Reduced the test case even more. The key part is the <center> tag around the table. Eliminate that and the problem does not happen

Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!

This was really the same problem as 22497, and that change (I just checked it in) has fixed this as well.

*spam* changing qa contact from nobody@mozilla.org to me (BlakeR1234@aol.com) on 121 open or resolved (but not verified) bugs. sorry for the spam everybody, but most of these bugs would just remain dormant and not checked by QA otherwise. I'm not sure how so many bugs have nobody as their QA contact, but I suspect this is the fault of some sort of bugzilla corruption that happened at some point (most of these bugs are in the 20000-26000 range, and I don't see where in the activity log that QA contact explicitly changed to nobody@mozilla.org) Anyways, sorry again for spam. If you really get annoyed, I'm usually available in #mozilla on IRC for torture.

verified fixed on 100208 (trunk) on win 98