260963 - bad rendering of the web page

Status: RESOLVED WORKSFORME

(SeaMonkey :: General, defect)

Description

[mimo]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.8a4) Gecko/20040921
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.8a4) Gecko/20040921

huge empty space at the beginning of the page

Reproducible: Always
Steps to Reproduce:
1.
2.
3.




I don't know if it's a mozilla problem, or bad coding by the webmestre of this
site, but this problem arise only in recent mozilla builds (I've also a PC
on windows with 1.8a2, and there everything is fine).

Comment 1

[Hermann Schwab]

broken Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a4) Gecko/20040918
 wfm   Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a4) Gecko/20040911

huge gap between top and menu/content

Boxmodel in 1.8a3: start x, y, width, heigth 
div class=top    :    0,    0, 784,  101
div    id=menu   :   10,  111, 152,  672
div class=content:  160,  101, 604, 3928
div class=footer :    0, 4029, 784,   76

in the broken rendering content has a height of 4577, that is an increase of
649, and seems to be the height of the gap.
The footer position y is accordingly grown from 4029 to 4678.

Comment 2

[Hermann Schwab]

bumping severity to major, as it is a one week old regression, and very visible,
as huge gap between two divs.
Seems <div id="menu"> is pushing down <div class="content">

Link to CSS:
http://www.inkscape.org/css/base.css


The validator buttons in the footer validate CSS, but not XML. The XML errors
are for some URLs in div class=content", don´t seem related to this bug.
Seems to be a layout issue, but I don´t have the time to make a testcase.

Comment 3

[Henrik Pauli]

I don't really see a difference between how Mozilla/5.0 (Windows; U; Windows NT
5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10 and Mozilla/5.0 (Windows; U; Windows
NT 5.1; en-US; rv:1.8a4) Gecko/20040922 render the page, nor any odd gap in fact.

Comment 4

[Hermann Schwab]

*** Bug 260938 has been marked as a duplicate of this bug. ***

Comment 5

[Hermann Schwab]

(In reply to comment #3)
> I don't really see a difference between how Mozilla/5.0 (Windows; U; Windows NT
> 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10 and Mozilla/5.0 (Windows; U; Windows
> NT 5.1; en-US; rv:1.8a4) Gecko/20040922 render the page, nor any odd gap in fact.

This bug was working in 1.8a4, and regressed lately, so Firefox isn´t affected.

I´m seeing this bug now on two websites, screen resolution 800x600,
http://www.inkscape.org/
http://vssdoclinks.mozdev.org/
http://www.mozdev.org/projects/active.html
http://www.mozdev.org/docs/


broken : Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a4) Gecko/20040918
broken : Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a4) Gecko/20040916
broken : Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a4) Gecko/20040914
working: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a4) Gecko/20040911

so oldest broken build now is BuildID 2004091406 on win98, 800x600

http://www.mozdev.org/docs/ is showing the bug on first load, and on
SHIFT-Reload, normal reload restores the layout.
http://www.inkscape.org/ is showing content shortly on correct posizion on
reload, but then also pushes content down.

Comment 6

[tomByrer]

Visiting several projects in mozdev.org, the middle column renders below the
lowest part of the left column (though remaining in the middle column) when you
click on the middle column's "resources" navigation on top.  (This navigation
usually has "Home  Mailing List  Installation  Source Code  Members 
Screenshots" links).  So it is like the left column becomes its own row.  It
will bounce back up if you resize or refresh the browser.  Same error is in the
20040921 Firfox trunk nightly.  However, these pages will render propperly in
Linux/Mozilla 1.7.1, & had before in my Mozilla 1.7beta on Win98se.

Looking at the HTML code, the mozdev pages look like a mish-mash of CSS columns
& tables.  The said "project-navigation" is contained in a table, which in turn
is in <div id="main-content">.  I checked several CSS 3-column examples at 
http://css-discuss.incutio.com/?page=ThreeColumnLayouts & there are a few that
have this error, though it doesn't look as bad:
http://www.liamdelahunty.com/tips/layouts/centre_box_three_columns_02.php

Reproducible: Always
Steps to Reproduce:
1. visit http://vssdoclinks.mozdev.org/
2. click on a link in "resources" navigation on top
3. middle column will drop
4. refresh/resize, midlle will return to the top

Expected Results:  
render the middle column flush to the top

Comment 7

[Hermann Schwab]

broken: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a4) Gecko/20040913

BuildID 2004091105 working
BuildID 2004091306 broken

checkins:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-09-11+00%3A00&maxdate=2004-09-13+08%3A00&cvsroot=%2Fcvsroot

Think, http://www.inkscape.org/ would be best for investigating a testcase.
only two divs between header and footer, and a link inbetween.
content is showing correctly while loading, but is pushed down as loading gets
further, reproducibly on Reload.
A local copy saved as webpage, complete, shows the bug without showing content
correctly while loading, as loading is fast from harddisk.

Comment 8

[tomByrer]

hmmm, the checkin diff you linked to has quite a few layout changes for "Bug
257216. Fix sundry block issues for columns. In particular, remove overflowing
floats from the space manager before we compute the space manager's XMost and
YMost to include in the block size. r+sr=dbaron"

Yes, the inkscape is a good, simple example.

Comment 9

[Hermann Schwab]

wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a4) Gecko/20040923
tested on another computer, also showing the bug with one of the buggy builds.

Comment 10

[tomByrer]

I tested on Yoper Linux, with a fresh nightly (Gecko/20040903) & got the
rendering error in all mozdev pages like before, but inkscape.org was working
fine.  I did an immediate comparison in Konqueror 3.3, & all the pages redered
as expected.

Comment 11

[Hermann Schwab]

resolving as WFM, as all commenters see it working now in current nightlies.
Bug has been resolved by mozilla, as it still can be seen with the buildIDs
mentioned here.
reopened the duped Bug 260938 with testcase attached, as this is still showing
the bug.