From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14-15mdk i686; en-US; m15) BuildID: 2000041811 when using 100% as the width value of a cascading style sheet, <select> elements do not render properly when the size attribute is also used. If you open the sample code that I'll attach, you'll see that the select (list) box ends before the end of the table cell. It should go all the way over. In comparison, look at the select (combo) box that renders correctly when the size attribute is not specified. Note that the difference between the end of the tag that is rendered incorrectly and the end of the table cell seems to be equal to the amount of space generally taken up by scroll bars. Is it possible that Mozilla is reserving room for the scrollbars, but then putting them in the wrong spot when they are needed and not releasing the space when they are not? Reproducible: Always Steps to Reproduce: 1.Open sample code. Note the difference between the combo box and the list box 2. 3. Actual Results: The list box (the select with the size attribute) never actually expands to 100% of its container. There is always a gap between the end of the list box and the end of its container. As I said before, this gap seems to be about the size of a scrollbar. The combo box (the select without the size attribute) scales appropriately. Expected Results: I would expect the list box's width (both with and without scroll bars) to be equal to the combo box's in every case with this style sheet applied.

Well, with build 2000053008, the stylesheet is now being ignored completely so my description of the problem is now incorrect. I'm including some screenshots to demonstrate the differences between what I was seeing and what I'm seeing now. I'll also include a screenshot of IE which renders the page as I would expect

PR1 and IE are sizing the select incorrectly. The spec says that when an element is sized to 100% and its container does not have a width specified, then it should be treated as auto. In the example here the container <td> doesn't have a specified width. If the example was: <td style="width:100%"> <select style="width:100%" size="4"> ... Then it size correctly except that the listbox's width is sized incorrectly by the width of the scrollbar.

I am nominating this for nsbeta2. listboxes (selects) are not sizing correctly when their width is specified via style. This is a regression. The fix very simple and very low risk.

oops, setting milestone to M16

/me sighs and shakes head..... Where in the spec do you see that the width should be treated as auto when the parent's width is not explicitly specified? In the CSS 1 spec section 5.5.23 it states "Percentage values: refer to parent element's width". Nowhere does it state that the parent element's width must be explicitly stated. Am I missing something? Also, please see bug 40596 for a similar issue I've reported. I am *very* concerned that mozilla is not going to be consistent with how it handles widths specified in percentages. Thanks for listening David

Here's the problem with this (I think I explained this on another, similar bug). If an element has 'width: 100%', then its *content*-width should be the same as its parent's content-width, so its border width (if it has a border) should be wider than the parent. If the parent (as table cells do) is determining its size based on the size of the child, this means the parent should get wider, which means the child should get wider, ad inf., leading to infinite width. (Similar arguments would *in some cases* cause the same problem to occur for widths that would make an element smaller than its parent.) The CSS model does not consider tables very well, and is based on the assumption that the size of the parent will always be determined before the size of the child. When this assumption is incorrect the model fails in weird ways. I tend to think that what rod said about percentage widths *should* be in the spec, but it isn't. (It is there for height. See http://www.w3.org/TR/REC-CSS2/visudet.html#x10 .) I think this should be clarified by the WG.

because clarification on the spec is needed I am removing nsbeta2

Putting on nsbeta2- radar. Nominating for nsbeta3 consideration pending clarification on standards.

The part I fixed I opened a new bug for, Bug 41300. because although was related it is a different issue

I filed a general bug on the table issues, bug 41306. Should this be marked as a duplicate of that bug, or a dependency?

It probably should, because at the moment I have nothing to fix here.

OK. This bug is now part duplicate of bug 36548 and part duplicate of bug 41306. Marking as duplicate of the latter (which I now suspect may be a regression -- see the original 3 comments on this bug). *** This bug has been marked as a duplicate of 41306 ***

Adding keyword to bugs which already show a nsbeta2 triage value in the status whiteboard so the queries don't get screwed up.

Updating QA contact.