TABLE inside FORM cannot set HEIGHT to 100%




18 years ago
17 years ago


(Reporter: Frank Faubert, Assigned: karnaze (gone))




Firefox Tracking Flags

(Not tracked)


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


(2 attachments)



18 years ago
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.  

This should be in the center of the page.

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

Comment 2

18 years ago
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.

Comment 3

18 years ago
*** Bug 51052 has been marked as a duplicate of this bug. ***

Comment 4

18 years ago
massive update for QA contact.
QA Contact: petersen → lorca

Comment 5

18 years ago
Frank, does this happen on any other platforms?  Win95, Win98, WinNT, MacOS8.6 
or MacOS9?  Linux?

Comment 6

18 years ago
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

Comment 7

18 years ago
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?
Ever confirmed: true
OS: Windows 2000 → All
Priority: P3 → P2
Hardware: PC → All
Dividing up claytons bugs to triage
Assignee: clayton → dcone

Comment 10

18 years ago
Assignee: dcone → karnaze

Comment 11

18 years ago
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.

Comment 12

18 years ago
Created attachment 16767 [details] [diff] [review]
patch to fix the bug


18 years ago
Keywords: rtm
Whiteboard: [rtm need info]

Comment 13

18 years ago

Comment 14

18 years ago
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

Comment 15

18 years ago
Just built Mozilla with the patch applied, NetTracker 5.0 looks perfect now!

Thank you for taking the time to crush this bug!!

Comment 16

18 years ago
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 -
Whiteboard: [rtm need info] → [rtm+] a=buster(changed from r=), r=pollmann

Comment 17

18 years ago
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

Comment 18

18 years ago
Created attachment 16925 [details]
additional case fixed by this patch: <iframe> pct height in form

Comment 19

18 years ago
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


18 years ago
Whiteboard: [rtm+] a=buster(changed from r=), r=pollmann → [rtm-] a=buster(changed from r=), r=pollmann

Comment 20

18 years ago
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>

Comment 21

18 years ago
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!

Comment 22

17 years ago
Now that NS6 RTM has occurred, is there any chance of this being committed to 
the Mozilla/NS6.01?

Comment 23

17 years ago
The patch is in.
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 24

17 years ago
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

Comment 26

17 years ago
qa contact updated.
QA Contact: gerardok → bsharma

Comment 27

17 years ago
build: 2000-03-07-10-Mtrunk
platform: WinNT
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.