247662 - selectbox with percentage value for css-property 'max-width' and nested inside a table

Status: RESOLVED WORKSFORME

(Core :: Layout: Form Controls, defect)

Description

[volker]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040614 Firefox/0.9
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040614 Firefox/0.9

selectbox nested inside a table is not displayed or doesn't show all options
when its css-property 'max-width' has a percentage value

Reproducible: Always
Steps to Reproduce:
1. nest a select inside a table
2. give the select a sufficent size for all options and a'max-width' style with
a percentuage value
3. select an option and reload the page

Actual Results:  
the selected option and all options above aren't displayed

Comment 1

[Mats Palmgren (inactive)]

Attachment: Reporter's testcase

Comment 2

[Mats Palmgren (inactive)]

Confirming bug, 2004-08-01-07 trunk Linux.

Funny, if I shift-reload a few times the select disappears altogether, using
DOM Inspector at that point shows a computed width of -4px (!) for the select

Comment 3

[Grant Wohl]

I may be wrong, but I thought that percentage length values were relative to the
containing element. See
<http://www.w3.org/TR/REC-CSS2/syndata.html#percentage-units>. Since no width
was provided for the second td in the second table, putting max-width:100% on
the select group means that the maximum width of the select element is 100% of
the td, which of course isn't anything since there is no width attribute and no
other content in the td.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

The first table is definitely a bug. The others are arguably correct. In
particular, Grant's right about the second one: it's a recursive definition ---
the max-content-width of the <select> is 100% of the table cell width, which is
going to be the desired width of the <select>, but the desired width is
constrained to be no more than the max-content-width + any border/padding. So
there is no well defined rendering there.

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

In any case, this didn't work in FF 1.0, so this is not a regression, and we
won't be fixing it for 1.8. dbaron's reflow refactoring might fix it.

Comment 6

[Boris Zbarsky [:bzbarsky]]

First table got fixed by something in this range: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-02-28+01&maxdate=2006-03-01+01&cvsroot=%2Fcvsroot

The second got fixed (or at least changed behavior) by the reflow branch landing.

Worksforme.  We need to add testcases for this, though...