Closed Bug 21834 Opened 20 years ago Closed 20 years ago

SELECT not sizing correctly inside a TABLE


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

Windows NT





(Reporter: keith.lesch, Assigned: buster)




(Keywords: css1, testcase)


(3 files)

There are still
problems when you are displaying the SELECT in a table, and assigning it widths
inside of widths.  In this example, there should be 2 SELECTs side by
side, one at 25% and the other at 75%.  Occasionally I have gotten these
controls to show up on the browser with a grey background that extends the
correct distance, but the part containing the options and pull-down arrow is
never any larger than the text it contains.  Please test the following example:

SELECT { width:100% }
function populate(inForm) {

   var option0 = new Option("Red", "color_red")
   var option1 = new Option("Blue", "color_blue")

   for (var i=0; i < 2; i++) {
      eval("inForm.selectTest.options[i]=option" + i)
      if (i==0) {
   inForm.selectTest.options.length = 0;

<H3>Select Option() constructor</H3>
<TABLE width="50%"><TR><TD width="25%">
<SELECT NAME="selectTest"></SELECT>
</TD><TD width="75%">
<SELECT NAME="selectTest2"></SELECT>
<INPUT TYPE="button" VALUE="Populate Select List" onClick="populate(this.form)">


I am working on Windows NT SP4 with Mozilla build 1999120919.
Summary: SELECT not sizing correctly inside a TABLE → {css1} SELECT not sizing correctly inside a TABLE
Whiteboard: [TESTCASE]
A much simplified test case (no scripting) can be found here:

Bsically, the error is visible in this:

     <option>This should span the whole container.</option>

...if you use this stylesheet:

   table { width: ...; }
   select { width: 100%; }

It appears SELECT elements are having difficulty getting the width of the parent
cell element.
The same problem applies if you replace the select element with an INPUT
Summary: {css1} SELECT not sizing correctly inside a TABLE → {css1} elements not sizing correctly inside a TABLE
Also a problem with TEXTAREA, SPAN, A.  Works with DIV, P, H*, TABLE.
Summary: {css1} elements not sizing correctly inside a TABLE → {css1} SELECT not sizing correctly inside a TABLE
SPAN and A should *not* 'work', as they are non-replaced inline elements, and
'width' does not apply to that type of element. SELECT is a _replaced_ inline
element (in this case) and so 'width' should work fine with it.

Note -- with 'display:block' on SELECT, the SELECT's outer box grows correctly
but it does strange things inside it...
The problem is in the line reflow optimization code. In
nsBlockFrame::PrepareResizeReflow, if the new line width is wide enough for the
current width of the line frames, and several other conditions are satisfied,
then the line is not marked dirty for reflow. One of the conditions that must be
satisfied is !line->HasPercentageChild(), which would seem to cover this case
... except SetHasPercentageChild() is never called, anywhere, ever.

I have attached a simpler test case that demonstrates this bug. Try opening the
file with the window very wide, then gradually make the window narrower. The
input box will not change width unless it is on a line by itself (in which case
the line is marked as containing a single block and is always reflowed). IE5
handles this case correctly.
OK, I have made a patch. It seems to work for simple tests. It does not fully
resolve the SELECT test case posted below ... there may be another bug specific
to the SELECT widget.

This patch might have some performance impact. The IsPercentageAwareChild check
 is fairly lightweight, but it is executed every time an inline frame is reflowed.
Looking at build 1999122608, the bug appears to be fixed for the initial layout.
However as you have noted the widgets do not resize with the window.  Also, the
widgets tend to grow every time you click on them.  If I click on a widget
enough times, I can grow it wider than the window itself, forcing the window to
scroll.  Note that this addition in width appears to be exactly the width of the
gray area that appears between the down arrow and the rightmost border of the
widget.  Is there any reason for that gray area to be there, and could it and
the growing be related?

Also, this patch has not yet affected the display of the TEXTAREA, INPUT, or
BUTTON widgets.  Note that the INPUT type=button resizes correctly after a
click.  Are these three cases directly related or should they be different bugs?
Something seems to have changed in the SELECT widget that fixes the "SELECT in
fixed-width table" case. The other widgets and resizing behaviour still do not
work. The fundamental problem addressed by my patch still exists --- that lines
are sometimes not reflowed when they need to be.
Assignee: karnaze → kipp
Reassigning based on comments/patch.
I thought kipp was no longer on the project. Why is it still possible to assign
bugs to him?
I now own Kipp's bugs, with lots of help from some other engineers. For now, it
is useful to keep "his" bugs in block/inline layout separate from "my" bugs in
other areas.  Eventually, all of Kipp's bugs will be reassigned.  Please see my
posting on netscape.public.mozilla.layout titled "What's up with Kipp's bugs?
Here's the scoop."
Target Milestone: M15
Keywords: css1
Migrating from {css1} to css1 keyword. The {css1}, {css2}, {css3} and {css-moz}
radars should now be considered deprecated in favour of keywords.
I am *really* sorry about the spam...
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase
<A HREF="showattachment.cgi?attach_id=4796">Created an attachment (id=4796)</A>
I really goofed, but I attached this to the wrong (but similar) bug #18448.  You 
will see that the SELECT element displays first at approx. 1/2 the correct 
length, and then about 75%.  The problem is that the TD does not know it needs 
to take up 100% of the remaining area.  If you define its width as such, this 
attachment will work.  Otherwise, this bug appears to be fixed as of M13.
If the TD is not defined at a width, the SELECT should (but does not) take up 
everything except the 200 already defined to the other TD.  So then it appears 
that the select element does not realize its maximum potential width until you 
click it a few times.  If the TD is defined at 100%, both elements take up all 
space that is not FILLed by another TD, thus leaving the other TD with only 
about a 70 width instead of 200.  I am not sure if the latter of these 
situations is correct, but explorer handles it this way as well.  

On a side note, I'm not perfectly sure how the "*" is supposed to work as no 
browsers support it yet, but...Mozilla appears to handle a "*" fine (probably 
ignores it) but not too well with a "2*" which I believe should mean half of 
what's left.  I tried setting each of the 2 cells to 2*, but it did not work too 
well.  Hope all this helps...
I will create a new bug for "replaced-inline elements styled with width:x% do 
not resize properly", and copy my patch and testcase over. I'm not sure if that 
problem is the cause of the remaining problems in this bug, but even if so, the 
table and SELECT issues are unnecessarily confusing.
These issues appear to only apply when the replaced elements are _inside of a 
table_.  The only exception is height of a textarea, of which percentages never 
work, but width does.
My test case attachment still has the "issues" that I explained in my comments
(I just checked using a build that I just FTPed from I've spun
this off into bug #26289 to avoid further confusion.
Summary: {css1} SELECT not sizing correctly inside a TABLE → SELECT not sizing correctly inside a TABLE
Whiteboard: [TESTCASE]
mine! mine mine mine!  all mine!  whoo-hoo!
Assignee: kipp → buster
FYI: I think the only problem left here is that the SELECT element's down arrow 
is only at the far right if you have an OPTION that is as wide as the SELECT.
Target Milestone: M15 → M16
moving all buster m15 bugs to m16.
I know I no longer have any problems with this bug.  The bug that was created 
from it has been verified fixed.  As far as I'm concerned this can be closed as 
marking fixed based on keith's comments.  Robert, is the patch you attached to 
this bug still relevant in any way?  If so, I'll look at it asap if you update 
it to the tip.
Closed: 20 years ago
Resolution: --- → FIXED
You already checked in my patch two months ago under bug #26289 :-). I have 
nothing to add.
Using Ian's testcase with 7/13 build, verified fixed.
You need to log in before you can comment on or make changes to this bug.