Closed Bug 120087 Opened 21 years ago Closed 20 years ago

Page is layed out with a top margin several pages high

Categories

(Core :: Layout, defect)

x86
All
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 102100
mozilla1.1alpha

People

(Reporter: kleist, Assigned: attinasi)

References

()

Details

(Keywords: testcase, top100)

Attachments

(3 files, 4 obsolete files)

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.
I see this too. Linux 2002-01-11-08 (trunk).
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
see comments in bug 99461
Depends on: 99461
*** Bug 120192 has been marked as a duplicate of this bug. ***
*** Bug 120483 has been marked as a duplicate of this bug. ***
*** Bug 121071 has been marked as a duplicate of this bug. ***
*** Bug 121121 has been marked as a duplicate of this bug. ***
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
Target Milestone: --- → mozilla1.0
*** Bug 121071 has been marked as a duplicate of this bug. ***
seems to me that the align="left" on one of the tables is causing the problem.
Attached file Testcase (obsolete) —
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.
Keywords: testcase
This is a top100 site. Adding appropriate keyword.
Keywords: top100
*** Bug 122166 has been marked as a duplicate of this bug. ***
*** Bug 122197 has been marked as a duplicate of this bug. ***
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.
*** Bug 123510 has been marked as a duplicate of this bug. ***
Blocks: advocacybugs
*** Bug 123819 has been marked as a duplicate of this bug. ***
Marking nsbeta1+
Keywords: nsbeta1+
*** Bug 123993 has been marked as a duplicate of this bug. ***
Works for me. Linux build 2002020714
Did the webmaster update the site CSS?
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
hoju@visi.com: 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.
Yes, the page definitely changed because it's now fine even with Mozilla0.9.8
release.
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
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.
Severity: major → normal
Keywords: nsbeta1+nsbeta1-
Target Milestone: mozilla1.0 → mozilla1.1
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
There might be a similar problem with the German version:

http://www.de.tomshardware.com/
Comment on attachment 66610 [details]
Testcase

test case bug repaired by fix for bug 122200
Attachment #66610 - Attachment is obsolete: true
Comment on attachment 66611 [details]
Testcase #2 - as above but no VSPACE on image

same
Attachment #66611 - Attachment is obsolete: true
****************************************

TESTCASE #3 IS THE TESTCASE FOR THIS BUG

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

http://bugzilla.mozilla.org/attachment.cgi?id=66612&action=view
Attached patch fix of width of table with image (obsolete) — Splinter Review
Width of table with image is wrong (i.e. width is larger).
Please ignore this patch, if already fixed.
I tested 0.9.8.
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.
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.
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".
> 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.
Attached file Testcase #4
Attachment #66612 - Attachment is obsolete: true
Attachment #74026 - Attachment is obsolete: true
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.
And see also bug 102100.
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?
See also the testcase (and snapshot) in bug 102216

*** This bug has been marked as a duplicate of 102100 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.