Closed Bug 289406 Opened 19 years ago Closed 19 years ago

floated elements vertically misaligned on initial render

Categories

(Core :: Layout: Floats, defect)

x86
All
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: frase, Unassigned)

References

()

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2

The above page (and others like it) is rendered incorrectly by recent Gecko
engines (I tried an older version (20040803 - in Mozilla 1.7.2) and couldn't
reproduce it so it seems to be a recent thing) - but only on the first load of
the page.  

Subsequent renders from cache fix the problem but a cache flush will allow the
problem to be reproduced.

Note that I haven't tried reproducing it on other operating systems (Only tried
Win2k/XP) yet but will ASAP.  In the meantime, if you are unable to reproduce
the problem in another environement please let us know.

I believe it probably has something to do with image loading because the problem
only becomes apparant after there are images in the main body of the document -
makes further sense that this could be part of the problem since once the images
are cached the problem goes away.  Resizing the browser/ changing the text/
reloading the page will result in it being re-rendered correctly.

Reproducible: Always

Steps to Reproduce:
1. Move away from problem page.
2. Flush cache.
3. Return to problem page.
Actual Results:  
the vertical misalignment of right-floated text was reproduced (after image
content appears in the document)

Expected Results:  
rendered the right-floated in line with the rest of the heading
That's a rather large page. Where is the issue, what does it look like, and how
does it differ from the correct rendering?

Also, try reproducing with a recent trunk nightly build from
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ as the
layout engine in 1.0.x is rather old.
if you scroll down the page to below where the images in the main content
appear, the 'back to top' text at the top of each entry is misaligned

sorry - I should have made that clearer in my original post :/  I will hopefully
get around to making a simpler, dedicated example of the problem soon.

I'll try the latest trunk build now, thanks.
Hardware: All → PC
Ok, I see the 'back to top' bit in the entry on 10-02-2005 on a line of its own
above the 'Posted by...' line in 1.0.2 and trunk 20050405, but only temporarily,
while loading; it goes away (as in, goes onto the same line) once all the page
content is loaded.
aha!  well I just tried it in 20050406 and it seems to be fine (loaded much too
quickly though for me to tell whether or not it appeared wrong while the images
were loading).

It was reported here:
http://forums.mozillazine.org/viewtopic.php?t=247056
that the problem was experienced in 20050402 but I couldn't reproduce the
problem in the latest trunk nightly so it appears it may already have been
fixed; but only in the last few days.
I can confirm that this problem affects the gecko engine running on other
platforms now - tried it on a solaris system (late 2k4 version of Gecko) and the
problem was experienced.

t
It's broken again in the latest nightly (20050407) - the scrollbar was curiously
absent from the previous nightly build so that might have had something to do
with it :/

t
Martijn, can you reproduce this?
The url has changed, see the last post with the forums.mozillazine link at
comment 4.
What I attached, is probably the situation when this bug was encountered.
However, I'm not able to reproduce this.

I can reproduce the bug with a 2005-04-20 build (100% reliable), but I can't
anymore with a 2005-04-22 build.
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-04-20+07%3A00%3A00&maxdate=2005-04-22+10%3A00%3A00&cvsroot=%2Fcvsroot


Perhaps this is fixed by fixing bug 290297?
I can see the problem in 1.7.8 and other older builds, but not able to reproduce
on current trunk.

Martijn's guess about bug 290297 fixing this is probably right, but I'm setting
this as WFM and not a dup as I don't think it is worth the trouble to really
verify that and besides, the info here doesn't add any value to that bug.

Reporter, reopen if I'm incorrect.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: