304146 - Bottom of page (footer) often misplaced and drawn in middle of page

Status: RESOLVED WORKSFORME

(Core :: Layout: Tables, defect)

Description

[Wayne Woods]

I tried fielding this on MozillaZine first, but got no responses...

Navigate to the URL I listed, or (in case it stops working) go to the World
Expeditions site (http://www.worldexpeditions.com.au), and use their menus to
generate a list of trips for a particular region. The list should be long enough
to scroll off the page. The test URL I entered should give you such a list.

The resulting page has a kind of "footer" consisting of a blue bar with "Site
Map", "Privacy" etc. on it, and a few other objects, such as a WWF logo, logos
for other organizations and a country selector.

In both IE in Windows, and Safari in OS X, the footer is rendered consistently
at the very bottom of the page.

In Firefox and SeaMonkey, however, the page footer is frequently drawn further
up the page, over the top of some of the trip listings, making the list look
much shorter.

The placement seems to vary. Sometimes it draws right, but if you hit reload,
then it may render it incorrectly the next time. I've tested it in the latest
Deer Park nightlies in both OS X and Windows.

This rendering inconsistency, plus the fact it works right in other browsers for
both platforms, suggests a browser problem rather than a problem with the page
code. But my html skills are crummy ;)

If I save the page locally and load it from my desktop, it ALWAYS draws
correctly. So could it be some sort of timing issue with rendering? i.e. If
certain elements aren't downloaded from the web fast enough, the footer gets
drawn before them??

Comment 1

[Martijn Wargers (dead)]

Attachment: testcase

This testcase uses the js hack to trigger the bug.

Comment 2

[Martijn Wargers (dead)]

The bug can also be seen in Mozilla1.7, so no (recent) regression.

Comment 3

[Wayne Woods]

Thanks for the test case, Martijn. Since I couldn't reproduce it when I saved
the page locally, I couldn't work out what was going on. So referencing
document.body.offsetHeight is causing the height miscalculation?

Comment 4

[Martijn Wargers (dead)]

Yes, see for an explanation what is happening, here:
http://weblogs.mozillazine.org/hyatt/archives/2003_08.html#003963

Comment 5

[Wayne Woods]

That's really handy, thanks!

Comment 6

[Bernd]

Martijn, this is wfm?

Comment 7

[Martijn Wargers (dead)]

Attachment: testcase without js hack

Comment 8

[Martijn Wargers (dead)]

Both testcases look the same, so this appears to be wfm, indeed.