Closed Bug 126742 Opened 20 years ago Closed 20 years ago

Bottom of table does not show up when it's height is defined (using either html or css)

Categories

(Core :: Layout: Tables, defect, P1)

x86
Windows 2000
defect

Tracking

()

VERIFIED FIXED
mozilla0.9.9

People

(Reporter: ariel_gonz, Assigned: karnaze)

References

()

Details

(4 keywords, Whiteboard: PATCH)

Attachments

(3 files, 1 obsolete file)

Build: 2002-02-20-03, Win2k

In the URL above, the page only displays the first 3 links, but there are 10
links total. BTW, that page is just one of the frames from
http://www.tech.purdue.edu/eet/courses/eet304/
Also, if you go to the "real" page ^^^^^^ when you hover over the links for the
first time, the bottom of the frame will turn white (it usually has a background
image) so that is weird also.

Anyway, this was working with build 2002-02-15. It was doing the white-box
thing, but at least you could see and use all the links on the page.
WFM, Linux CVS (pulled just after the freeze).
Amongst many other errors (it seems that a wysiwyg editor has been used), the
above page contains an invalid HEIGHT attribute in the <table> element. After
removing this attribute, the page is rendered as expected. Suggesting resolution
INVALID, unless we want Mozilla not to be confused from this (admittedly, most
pages written with MS tools do repeat this error).
Forgot to update summary: from "Bottom of page does not show up" to "Bottom of
table does not show up when the invalid table HEIGHT attribute is used".
Summary: Bottom of page does not show up → Bottom of table does not show up when the invalid table HEIGHT attribute is used
If it's an HTML error, I'll do some advocacy (he's my professor)... but the page
looked fine with the last build I downloaded, so thats kinda weird. Also, I just
loaded hotmail.com and the page was also rendered halfway down... once I started
typing in the text boxes it fixed itself... very weird... but I havent been able
to reproduce it so I won't post a bug on that yet...
It's easy to check for html errors by using the W3C Html validator at
http://validator.w3.org/. Although personally I think this bug must be
invalidated, I am attaching a simplified test case. In that file, if one removes
the height="380" attribute in line 7, then it is rendered as expected.
Attached file simplified testcase
Target Milestone: --- → mozilla1.2
Priority: -- → P3
Changing QA contact
QA Contact: petersen → amar
*** Bug 127325 has been marked as a duplicate of this bug. ***
*** Bug 127372 has been marked as a duplicate of this bug. ***
What's with the summary here? HEIGHT was deprecated in HTML 4.0 but W3C states:
"User agents should continue to support deprecated elements for reasons of
backward compatibility."

The documents in question either state 4.0 or have no DTD set at all.
I very much doubt this bug is invalid, and it also affects top100 sites.

This is a recent regression, and on Linux it can only be seen when building CVS
with --disable-dtd-debug. I can't quite see why i should be forced to build
debug-builds in order to enjoy web content.

Changing component.
Assignee: attinasi → karnaze
Severity: normal → major
Component: Layout → HTMLTables
Keywords: 4xp, regression
>HEIGHT was deprecated in HTML 4.0 but W3C states:
"User agents should continue to support deprecated elements for reasons of
backward compatibility."

The key point here is that HEIGHT inside a <table> tag is invalid, not
deprecated. See
http://www.w3.org/TR/1999/REC-html401-19991224/struct/tables.html#adef-height-TH
for details. I agree that it's better to gracefully ignore it as we (I mean
Mozilla, excuse me for including myself in an effort where I have rather
insignificant presence) did in the past.
You refer to the HTML 4.01 spec, and the word used by W3C isn't "Invalid" - it's
"Deprecated" - the quote i earlyer pasted is as relevant.

Apart from that: None of the pages in question claim to be HTML 4.01.
adding more keywords
Keywords: compat, top100
R.K.Aa., perhaps I was a bit unclear. I consider invalid everything that is
missing from W3C specification. Deprecated elements/attributes *are* mentioned
in the specification. To verify what I'm saying, run the testcase on W3C
validator. It will clearly report an error. Deprecated elements doesn't produce
errors.
But. as you can see in comment #2, I 'm not insisting on invalidating this bug.
Agreed?
Keywords: compat, top100
*** Bug 127170 has been marked as a duplicate of this bug. ***
I can't even build without --disable-dtd-debug because I'm using win32 nmake.
Something must be wrong if i can see the problem only in non debug builds..

If an element is invalid, mozilla should ignore it but don't break many sites

*** Bug 127429 has been marked as a duplicate of this bug. ***
*** Bug 127053 has been marked as a duplicate of this bug. ***
Not sure it's the same bug but mshop.no serve adds for many of the countrys
largest websites. Now they appear with white areas where the add should have been:

http://www.aftenposten.no
http://www.itavisen.no

Sample blank URL:
http://www.mshop.no/adilog/shop5/index2.html
Open in a window, resize a couple of times: content will appear and vanish like
magic.
Adding "compat" keyword.  "height" is a valid (but deprecated) attribute for
<th> and <td>, but not <table>.  But we should ignore the attribute, not let it
destroy the table.  Since this seems to be limited to builds with
--disable-dtd-debug, maybe this is a parser issue.
Keywords: compat, testcase
another broken site:
http://www.trolltech.com/
This problem reproduced using height property of CSS on table element.

Bugzilla-jp's Test Case. Here.
http://bugzilla.mozilla.gr.jp/showattachment.cgi?attach_id=581
http://bugzilla.mozilla.gr.jp/showattachment.cgi?attach_id=582

Attatchment-jp 581 and Attachment-jp 582 are not used height attribute.
Is this Invalid HTML?

Attachment-jp 581
   Table height value < Table cells height values......Good.
   Table height value > Table cells height values......Layout Broken.

Attachment-jp 582
   Table has only one tr element.......Good.
   Table has over two tr elements......Layout Broken.
Clearing milestone and priority. Thse were set before component was changed (and
before the dups started pouring in). They should be reconsidered.
IMO this should be a 0.9.9 bug.
Priority: P3 → --
Target Milestone: mozilla1.2 → ---
Confirming Masayuki Nakano's comment #22. Changing summary from "Bottom of table
does not show up when the invalid table HEIGHT attribute is used" to "Bottom of
table does not show up when it's height is defined (using either html or css)"
Summary: Bottom of table does not show up when the invalid table HEIGHT attribute is used → Bottom of table does not show up when it's height is defined (using either html or css)
www.protonradio.com is hit by this on a win32 trunk build (opt).
removing --disable-dtd-debug from .mozconfig made no change.

To repeat what i said in one of the bugs later resolved as duplicates:
I see this bug in CVS builds, but not in an official nightly from 2002022208
(Linux)
http://www.stortinget.no - homepage of the Norwegian Parliament
Main area mostly white in a CVS build. 2002022208 renders it fine.
I build with --enable-optimize=-O2
The nightly builds on Linux aren't optimized! That's probably why the bug
doesn't appear there. Somewhere along the road, vital code is optimized away.
Attached file testcase
it seems that when the first td's height is not set it solves the problem.
There is no HTML problem in this bug. The problem is that good code is optimized
away. In non-optimized builds the bug doesn't exist, at least not on Linux.
sorry "it seems that when the first td's height is not set it solves the
problem." should have read "it seems that setting first td's height causes the
problem."
>good code optimized away

couldn't that be  a UMR ?
Chris Karnaze checked in the border collapse code just before the freeze and the
tinderbox warnings went up, some of them include a uninitialized use, so it may
be a good idea to fix the new warnings first.
*** Bug 127595 has been marked as a duplicate of this bug. ***
*** Bug 127593 has been marked as a duplicate of this bug. ***
I think this might also be the problem of this site:
http://marvin.sn.schule.de/~cre8ics/lernumgebung/index.php

Worked great before. And yeah, table heights are used, but only in CSS.
*** Bug 127664 has been marked as a duplicate of this bug. ***
Severity: major → critical
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla1.0
Attached patch patch to fix the bug (obsolete) — Splinter Review
Likely caused by bug 41262.
Whiteboard: PATCH
Comment on attachment 71338 [details] [diff] [review]
patch to fix the bug

sr=attinasi
Attachment #71338 - Flags: superreview+
Blocks: 122050
Comment on attachment 71338 [details] [diff] [review]
patch to fix the bug

r=kin@netscape.com
Attachment #71338 - Flags: review+
Marking nsbeta1+
Keywords: nsbeta1nsbeta1+
Comment on attachment 71338 [details] [diff] [review]
patch to fix the bug

a=shaver for 0.9.9.  (Should nsMargin have a default constructor that sets
0,0,0,0?)
Attachment #71338 - Flags: approval+
Attachment #71338 - Attachment is obsolete: true
Attached patch correct patchSplinter Review
I made the mistake of thinking that the fix was so simple that I could get
approvals before complete testing.
Comment on attachment 71391 [details] [diff] [review]
correct patch

doh! sr=attinasi
Attachment #71391 - Flags: superreview+
Comment on attachment 71391 [details] [diff] [review]
correct patch

r=
Attachment #71391 - Flags: review+
Comment on attachment 71391 [details] [diff] [review]
correct patch

a=shaver for 0.9.9.  So nice they approved it twice!
Attachment #71391 - Flags: approval+
The patch is in.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.0 → mozilla0.9.9
*** Bug 127822 has been marked as a duplicate of this bug. ***
All testcases (including those from bugzilla.mozilla.jp) are working now on
Win98, build 2002022603.
*** Bug 127563 has been marked as a duplicate of this bug. ***
*** Bug 127882 has been marked as a duplicate of this bug. ***
*** Bug 127599 has been marked as a duplicate of this bug. ***
*** Bug 128490 has been marked as a duplicate of this bug. ***
 The testcases works fine. Marking verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.