Closed
Bug 21834
Opened 25 years ago
Closed 25 years ago
SELECT not sizing correctly inside a TABLE
Categories
(Core :: Layout: Tables, defect, P3)
Tracking
()
VERIFIED
FIXED
M16
People
(Reporter: keith.lesch, Assigned: buster)
References
()
Details
(Keywords: css1, testcase)
Attachments
(3 files)
|
(deleted),
text/html
|
Details | |
|
(deleted),
patch
|
Details | Diff | Splinter Review | |
|
(deleted),
patch
|
Details | Diff | Splinter Review |
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:
<html>
<head>
<STYLE>
SELECT { width:100% }
</STYLE>
</head>
<body>
<SCRIPT>
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[i].selected=true
}
}
inForm.selectTest.options.length = 0;
}
</SCRIPT>
<H3>Select Option() constructor</H3>
<FORM>
<TABLE width="50%"><TR><TD width="25%">
<SELECT NAME="selectTest"></SELECT>
</TD><TD width="75%">
<SELECT NAME="selectTest2"></SELECT>
</TD></TR></TABLE>
<INPUT TYPE="button" VALUE="Populate Select List" onClick="populate(this.form)">
<P>
</FORM>
</body>
</html>
I am working on Windows NT SP4 with Mozilla build 1999120919.
|
||
Updated•25 years ago
|
Summary: SELECT not sizing correctly inside a TABLE → {css1} SELECT not sizing correctly inside a TABLE
Whiteboard: [TESTCASE]
|
|
||
Comment 1•25 years ago
|
||
A much simplified test case (no scripting) can be found here:
http://www.bath.ac.uk/%7Epy8ieh/m/widgets/14.html
Bsically, the error is visible in this:
<table>
<tr>
<td>
<select>
<option>This should span the whole container.</option>
</select>
</td>
</tr>
</table>
...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.
|
Reporter | |
Comment 2•25 years ago
|
||
The same problem applies if you replace the select element with an INPUT
type=text.
|
|
Reporter | |
Updated•25 years ago
|
Summary: {css1} SELECT not sizing correctly inside a TABLE → {css1} elements not sizing correctly inside a TABLE
|
|
Reporter | |
Comment 3•25 years ago
|
||
Also a problem with TEXTAREA, SPAN, A. Works with DIV, P, H*, TABLE.
|
|
||
Updated•25 years ago
|
Summary: {css1} elements not sizing correctly inside a TABLE → {css1} SELECT not sizing correctly inside a TABLE
|
|
||
Comment 4•25 years ago
|
||
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.
|
|
Reporter | |
Comment 9•25 years ago
|
||
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.
|
||
Updated•25 years ago
|
Assignee: karnaze → kipp
|
|
||
Comment 12•25 years ago
|
||
Reassigning based on comments/patch.
I thought kipp was no longer on the project. Why is it still possible to assign
bugs to him?
|
Assignee | |
Comment 14•25 years ago
|
||
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."
|
|
||
Comment 15•25 years ago
|
||
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...
|
||
Comment 16•25 years ago
|
||
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase
|
|
Reporter | |
Comment 17•25 years ago
|
||
<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.
|
|
Reporter | |
Comment 18•25 years ago
|
||
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.
|
|
Reporter | |
Comment 20•25 years ago
|
||
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 mozilla.org). I've spun
this off into bug #26289 to avoid further confusion.
|
||
Updated•25 years ago
|
Summary: {css1} SELECT not sizing correctly inside a TABLE → SELECT not sizing correctly inside a TABLE
Whiteboard: [TESTCASE]
|
|
Reporter | |
Comment 23•25 years ago
|
||
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.
|
||
Comment 24•25 years ago
|
||
moving all buster m15 bugs to m16.
|
|
Reporter | |
Comment 25•25 years ago
|
||
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
well.
|
|
Assignee | |
Comment 26•25 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
You already checked in my patch two months ago under bug #26289 :-). I have
nothing to add.
|
||
Updated•24 years ago
|
Status: RESOLVED → VERIFIED
|
|
||
Comment 28•24 years ago
|
||
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.
Description
•