120087 - Page is layed out with a top margin several pages high

Status: RESOLVED DUPLICATE of bug 102100

(Core :: Layout, defect)

Description

[Karl Johan Kleist]

Build ID: 2002 01 11 03. Windows 2000.

When visiting this URL, one has to scroll down several pages
to see the contents. Opera 6 and IE 5.5 works fine.

Comment 1

[Mats Palmgren (inactive)]

I see this too. Linux 2002-01-11-08 (trunk).

Comment 2

[Boris Zbarsky [:bzbarsky]]

see comments in bug 99461

Comment 3

[Boris Zbarsky [:bzbarsky]]

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

Comment 4

[Olivier Cahagne]

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

Comment 5

[R.K.Aa.]

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

Comment 6

[R.K.Aa.]

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

Comment 7

[Jacob Kjome]

Here's a curious one.  Where the tomshardware pages have the huge margin at the 
top, the following page has a large amound of vertical space between content at 
the top and content at the bottom:

http://www.frontierlabs.com/NexII.html

Jake

Comment 8

[Chris Petersen]

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

Comment 9

[basic]

seems to me that the align="left" on one of the tables is causing the problem.

Comment 10

[Mats Palmgren (inactive)]

Attachment: Testcase

Comment 11

[Mats Palmgren (inactive)]

Attachment: Testcase #2 - as above but no VSPACE on image

Comment 12

[Mats Palmgren (inactive)]

Attachment: Testcase #3 - as above but without the image

Comment 13

[Mats Palmgren (inactive)]

Results of reload operations on the 3 first testcases:

1st testcase (attachment 66610 [details]):
  reload: first displayed at correct y-position (i.e. without the vertical gap),
          then jumps down and stays there.
  shift+reload: stays at the wrong position

2nd testcase (attachment 66611 [details]):
  reload: same as in 1 (jumps back and forth.)
  shift+reload: displayed at correct position (and stays). It works!

3rd testcase (attachment 66612 [details]):
  reload and shift+reload: Works fine. This is only to show that it's the image
     that is the cause of the problem.

Comment 14

[Mats Palmgren (inactive)]

Old URL http://www4.tomshardware.com/display/02q1/020114/index.html does not
trigger the bug anymore. Changing it to http://www.tomshardware.com/ which does
show the problem.

Comment 15

[André Dahlqvist]

This is a top100 site. Adding appropriate keyword.

Comment 16

[R.K.Aa.]

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

Comment 17

[Georg Wild]

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

Comment 18

[Boris Zbarsky [:bzbarsky]]

Please do not dup bugs that are not about tomshardware to this one.  See bug
99461 for details; Chris Waterson has asked that all affected sites get separate
bugs.

Comment 19

[R.K.Aa.]

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

Comment 20

[Matthias Versen [:Matti]]

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

Comment 21

[Kevin McCluskey (gone)]

Marking nsbeta1+

Comment 22

[R.K.Aa.]

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

Comment 23

[Vadim Berezniker]

Works for me. Linux build 2002020714
Did the webmaster update the site CSS?

Comment 24

[Jacob Kjome]

The problem isn't gone, it only changed a bit.  Now, instead of the top of the 
page having a huge margin, one of the lower left hand nav bar has a top margin 
that is too high.  Part of the left nav bar is layed out fine, but then there 
is a big gap and the rest of the left nav bar starts where the lowest part of 
the main center content of the page ends.

Not sure what was changed in the html, but there likely was a change made.  I 
don't think it has much to do with css since the site uses very little if any 
of it.  It is pretty much html 3.02.

jake

Comment 25

[basic]

[e-mail]: which build are you testing with?

with build 2002020603 win32 the above URL looks fine to me

the testcase 1 and 2 however still show the problem.

Comment 26

[Tom Mraz]

Yes, the page definitely changed because it's now fine even with Mozilla0.9.8
release.

Comment 27

[Jacob Kjome]

That was with build 2002020703 on Win2k (SP2).  The URL was:
http://www.tomshardware.com/

I just retested and am seeing the same problem as I mentioned in comment 24.

One correction.  What I called the bottom left hand nav bar is actually the 
right hand nav bar.  It is labeled "Columns" at the top.

You have to scroll all the way down to see this.  It will look correct if you 
just load it and see the top of the page. The top of it starts where the bottom 
of the content in the middle ends.

Ok, hold on a minute.  Try this.  Drag the right side of the browser to the 
left making the browser horizontally thinner.  Now I see the top left hand nav 
bar at the top, followed by the center content, followed by the right hand nav 
bar.  These are stacked vertically.  This is correctable if you make your 
browser wide enough to fit it all.

I don't see that behavior with IE6.  I can make the browser as thin or as wide 
as I want and the page lays out as expected.

Jake

Comment 28

[Kevin McCluskey (gone)]

Marking nsbeta1-. Moving to Moz1.1 for the remaining issues. The major issue the
huge margin at the top of the page is gone now.

Comment 29

[Jacob Kjome]

Actually, with today's build on Win2k (SP2), I now don't even see the issue 
that I mentioned in comment 27.  Almost seems like a WFM now.  

Jake

Comment 30

[Titus Jonas]

There might be a similar problem with the German version:

http://www.de.tomshardware.com/

Comment 31

[Alexandru Savulov]

Comment on attachment 66610 [details]
Testcase

test case bug repaired by fix for bug 122200

Comment 32

[Alexandru Savulov]

Comment on attachment 66611 [details]
Testcase #2 - as above but no VSPACE on image

same

Comment 33

[Alexandru Savulov]

****************************************

TESTCASE #3 IS THE TESTCASE FOR THIS BUG

****************************************

http://bugzilla.mozilla.org/attachment.cgi?id=66612&action=view

Comment 34

[Hideo Saito]

Attachment: fix of width of table with image

Width of table with image is wrong (i.e. width is larger).
Please ignore this patch, if already fixed.
I tested 0.9.8.

Comment 35

[Hideo Saito]

Attachment: fix of width of table with right-aligned image

My patch "74026: fix of width of table with image" is effective for
left-aligned image tag, but not effective for right-aligned image tag.

In case of Testcase of right-aligned image tag, red space appear on the right
side.

Comment 36

[Hideo Saito]

Attachment: fix of width of table with left-aligned image

My patch "74026: fix of width of table with image" is wrong.
Because long string larger than width of table tag can not expand its width.

I try another way to subtruct "mLeftEdge" from computed width.
In case of this patch, long string can expand width of table.

Comment 37

[Hideo Saito]

My 1st patch "fix of width of table with image" is obsolete.

If you test my patch, please apply both 2nd patch 
"fix of width of table with right-aligned image" and 3rd patch
"fix of width of table with left-aligned image".

Comment 38

[Mats Palmgren (inactive)]

> Alexandru Savulov wrote in comment 33:
>   TESTCASE #3 IS THE TESTCASE FOR THIS BUG

That was not my intention with the testcases. Testcase 2 and 3 was only provided
to show that the bug did not occur without VSPACE or without the (float) image.
Testcase 3 is rendered correctly AFAICT, at least it matches what IE6 and Opera6
does. Mozilla has changed slightly since I did the testcases, so now the bug also
occurs in Testcase 2.

I will provide a new simplified testcase that I hope will illustrate the bug more
clearly.

Comment 39

[Mats Palmgren (inactive)]

Attachment: Testcase #4

Comment 40

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 87814 [details]
Testcase #4

I believe all four of these examples are laid out correctly.  The difference
between TABLE and DIV is that the 'width' property on a DIV sets the width,
whereas the WIDTH attribute on a TABLE gives a minimum on the width, which can
be made larger if the minimum size of the contents is larger.

The minimum width of the contents of the table should be the sum of the width
of the floating image and the minimum width of the word "motherboard".

The "Example 1 [BUG]" in this testcase is a duplicate of bug 132021, and the
behavior is explained in more detail in bug 132021 comment 7 and in bug 97383. 
However, note that this behavior is still not completely correct -- see bug
156629 comment 12.

Comment 41

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

And see also bug 102100.

Comment 42

[Mats Palmgren (inactive)]

David, thanks for the explanation and pointers.
I agree that "Example 1 [BUG]" in "Testcase #4" is a duplicate of bug 132021 and
I think bug 102100 is the same too.

So should we mark this bug as a duplicate of bug 102100 to consolidate things?

Comment 43

[Mats Palmgren (inactive)]

See also the testcase (and snapshot) in bug 102216

Comment 44

[Boris Zbarsky [:bzbarsky]]

*** This bug has been marked as a duplicate of 102100 ***