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".

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.

Changing QA contact

*** 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.

>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

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?

*** 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.

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.

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)"

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.

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. ***

Likely caused by bug 41262.

Comment on attachment 71338 [details] [diff] [review] patch to fix the bug sr=attinasi

Comment on attachment 71338 [details] [diff] [review] patch to fix the bug r=kin@netscape.com

Marking nsbeta1+

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?)

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

Comment on attachment 71391 [details] [diff] [review] correct patch r=

Comment on attachment 71391 [details] [diff] [review] correct patch a=shaver for 0.9.9. So nice they approved it twice!

The patch is in.

*** 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.