When the page is first painted the lower text is rendered across the whole
browser width, then the lower right image is rendered under the text. A resize
of the window will correct the layout, as will a cached reload. Shift-reload
will repaint incorrectly.
I suspect the problem is that the images contain height tags, but no width tag
and are initially placed with a width of 0, once they load however they pop out
to their normal width but the rest of the view is not adjusted. Perhaps when the
image width is corrected an invalidate needs to happen to the rest of the layout?
while this isn't the cleanest HTML in the world I think it can be handled
better; if they complain about the reflow flash then tell them to clean up their
html and it wouldn't happen.
bah, forgot to mention that the build id is 2001011408.
OS: Linux 2.2.16
Mozilla Build: 2001011608
Really Marking NEW.
Created attachment 28197 [details]
a sample test case from the page
I gave the image a width value of 200 pixels but doen't seem to resolve the
Reassigning to attinasi and moving to m1.0.
cleared url, as the page has been completely redesigned. Also kicking my self
for not capturing a copy. (old url: http://ariss.gsfc.nasa.gov/ )
Fortunately the testcase attached shows the problem (assuming that the list
items over the image was the problem!)
while that is a valid problem, and is similar, it isn't the one I originally
meant. I'll see if I can coble together a second test case. The key information
should be that the images only have one dimension given in the html, and thus
their rendering changes when they finish loading.
I suspect that in a newer (libpr0n equiped) build it would assert because of the
zero width. (enough other stuff does)
Created attachment 46063 [details]
More optimized testcase
Seems like bug 802 has regressed. We should really figure out what CSS3 will
say about intrusions and list bullets, and implement that...
Ian: Is there another bug on this?
There is a bug on the initial floating image size not being updated when the
image comes in, and there are bugs on -moz-float-edge sucking, but I don't know
if this is either of those bugs.
Ian, the problem I was originally reporting is the first of those two, the
problems demonstrated in the attachments todate are the second.
Created attachment 46176 [details]
original case - now seems fixed
The test case I've just attached is a recreation of the problem I was originally
reporting. It does not however fail with a modern build. If y'all want to keep
the bug open for the list item problem you've been discussing that's fine by me,
but the original problem has been resolved for a while.
Can we add bullets to the summary or is this bug more general?
The URL I've just posted is a *current* example of the original problem I opened
this bug for - look at the two inline pictures and the text below them.
Screenshot and a static copy of the page in question are on
http://cabbey.net/bugzilla/ ... I'll see about trimming this down from there,
but it looks like it's a floating table containing an image without any
dimensions in the html. These were taken from a build on a fresh extract this
*** Bug 111109 has been marked as a duplicate of this bug. ***
How is this different from bug 57882?
*** This bug has been marked as a duplicate of 57882 ***