Closed Bug 50695 Opened 24 years ago Closed 24 years ago

TABLE inside FORM cannot set HEIGHT to 100%

Categories

(Core :: Layout, defect, P2)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: frank, Assigned: karnaze)

References

(
URL
)

Details

(Keywords: compat, Whiteboard: [rtm-] a=buster(changed from r=), r=pollmann)

Attachments

(2 files)

patch to fix the bug
(deleted), patch
Details | Diff | Splinter Review
additional case fixed by this patch: <iframe> pct height in form
(deleted), text/html
Details
Note: I picked Form Submission as the component because thats where bug #30988 wound up. This is an offshoot from that bug. Build ID: 2000082908 on Windows 2000 The above URL is a real world example of what this bug causes (see the bottom frame). The HTML below is a simplified testcase. <HTML><BODY> <FORM> <TABLE WIDTH="100%" HEIGHT="100%" BORDER=1><TR><TD VALIGN=CENTER ALIGN=CENTER> This should be in the center of the page. </TD></TR></TABLE> </FORM> </BODY></HTML> The text appears in the center of the page (both horizontally and vertically) in Navigator 4.x, IE 5.x and Opera 4.x. The text appears horizontally centered and flushed to the top of the page in Mozilla. If you put the FORM inside the TABLE, it works fine. Unfortunately that is not an option for all the places that this bug bites us in our real world HTML, as we have multiple tables doing layout inside a single FORM. If you use a number (ie: 100) instead of a percentage for the HEIGHT attribute, it works fine. The percentage seems to be what is throwing it off.
According to the CSS2 spec, we are correct. The TABLE's containing box doesn't have an explicit height, so we treat percentages as 'auto'. You should probably be using fixed positioning to achieve the effect you want per the standards.
Assignee: rods → clayton
Component: Form Submission → HTML Element
Keywords: compat
QA Contact: ckritzer → petersen
Thank you for the clarification. I don't disagree with you. However, I am not using CSS - just old compat HTML. Seeing as the spec does not give a specific height, and Nav 3.x/4.x, IE, and Opera all vertically center the text, it would be nice for Mozilla/NS6 to do so as well. Also, seeing as what I really want to do place the contents of the table in the vertical center of a page that can be pretty much any size, a fixed position will not work for me.
*** Bug 51052 has been marked as a duplicate of this bug. ***
massive update for QA contact.
QA Contact: petersen → lorca
Frank, does this happen on any other platforms? Win95, Win98, WinNT, MacOS8.6 or MacOS9? Linux?
I just tried it on a variety of platforms and it happens on all of them. Here are the platforms and Build IDs that I tested: RedHat Linux 6.2 : 2000090708 Solaris 2.8 (Sparc): 2000090621 Windows 2000 SP1 : 2000090704 MacOS 8.6 : 2000090704
Is there any chance that this can be escalated to P1 and fixed for NS6 RTM? This bug bites us in the behind all over the place in our product. We have made MANY changes to our next release (which has already gone gold) to make it work correctly and look great with NS6. This is the last remaining bug that we have an issue with. As you can see from the previous comments, even if we hadn't already gone gold and still could make changes, there wasn't a good workaround that we could have implemented. A fixed position doesn't help us, as we are trying to vertically center content in a page that could be of any height.
This is a pretty major compat issue. Raising to P2 and confirming. Before fixing it, we need to understand the backwards-compatibile behavior: What does height="100%" mean? Does it mean 100% of the height of the (a) viewport, (b) viewport minus margin of root element (c) viewport minus margin, border, and padding of HTML and BODY (d) something else? Is it setting the margin-height or border-height of the table (I assume it's the same as what pixel-heights do? How does it work inside a table cell (a) with an unspecified height (b) with a specified height?
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
Priority: P3 → P2
Hardware: PC → All
Dividing up claytons bugs to triage
Assignee: clayton → dcone
Triage...
Assignee: dcone → karnaze
I think we are not compatible in other % height cases, but this bug is a prime example. The % height basis is the viewport height adjusted to exclude the margin, border, padding of the html and body. Currently, the table only gets an artifical height basis (because its parent doesn't have a computed height) if the table is (1) inside the body or (2) inside the html (which I think can happen if the body has a display of table). This should probably be changed to allow the artifical height basis to be computed even if the table's parent is not the body or html, but that may be a bit risky at this point. As a very safe hack we could make it work if the table's parent is a form. I'm CCing Buster and Pollmann because I think they use this code as well for iframe and img, and such a hack may have a positive compatiblity effect on them.
Status: NEW → ASSIGNED
Attached patch patch to fix the bug (deleted) — — Splinter Review
Keywords: rtm
Whiteboard: [rtm need info]
r=buster
I think this is a great compatability improvement, and can't think of any downside. This change would allow compatability of <IFRAME> percentage height inside forms as well! r=pollmann
Just built Mozilla with the patch applied, NetTracker 5.0 looks perfect now! Thank you for taking the time to crush this bug!!
Marking rtm+. When a page hits this bug it is very noticeable. bug 42543 may be a dup of this and provide yet another url - http://www.ticketonline.de/
Whiteboard: [rtm need info] → [rtm+] a=buster(changed from r=), r=pollmann
Looked at the URL provided in mozilla, and it doesn't look that bad. Compared to the other must-fix/crash/data loss bugs we're fixing this week, I think this one is [rtm-]
Whiteboard: [rtm+] a=buster(changed from r=), r=pollmann → [rtm-] a=buster(changed from r=), r=pollmann
discussed with ekrock and clayton and decided rtm-. Please go ahead and fix this on the trunk.
Whiteboard: [rtm-] a=buster(changed from r=), r=pollmann → [rtm+] a=buster(changed from r=), r=pollmann
Whiteboard: [rtm+] a=buster(changed from r=), r=pollmann → [rtm-] a=buster(changed from r=), r=pollmann
Frank, since you are generating your own html, can you wrap the <form> inside a table as a workaround. You could do something like: <table cellspacing=0 cellpadding=0><form></table> <table height=100% border><tr><td><input type=submit></td></tr></table> </form>
I just tried the workaround and it solves the problem. I'm surprised that it is legal and that it doesn't break anything in IE, NS 3.x/4.x, or Opera, but it works fine. Unfortunately we shipped our product a few days ago, so I can't get this workaround in until a future version. By then I'm hoping that the problem will be fixed in Mozilla/NS6.01 instead. :) Thanks for your help Chris!
Now that NS6 RTM has occurred, is there any chance of this being committed to the Mozilla/NS6.01?
The patch is in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Sweet. Just installed 2000112920 on Win2k and it looks great! Thanks for your help Chris!
Reassigning QA Contact for all open and unverified bugs previously under Lorca's care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
qa contact updated.
QA Contact: gerardok → bsharma
Verified. build: 2000-03-07-10-Mtrunk platform: WinNT
Status: RESOLVED → VERIFIED
SPAM. HTML Element component deprecated, changing component to Layout. See bug 88132 for details.
Component: HTML Element → Layout
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: