Closed Bug 18448 Opened 25 years ago Closed 25 years ago

{css1} 'width' buggy with TEXTAREA and SELECT

Categories

(Core :: Layout: Form Controls, defect, P3)

x86
Windows 98
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: ian, Assigned: rods)

References

()

Details

(Keywords: css1)

Attachments

(1 file)

The 'width' CSS property is not being strictly adhered to for TEXTAREA and SELECT elements. See, for example, the following test case: http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/widgets/02.html There is an overflow problem on that page too; I will file it separately.
Assignee: karnaze → rods
Reassigning to Rod.
it is how they are handling the box-sizing attr
Status: NEW → ASSIGNED
The textarea should now be fixed. I am working on the select now.
changed to M14
QA Contact update.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
I changed some of the sizing code to take out where we were subtracting out the border and padding. Tested with the provided example - fixed
I agree that this bug has been fixed...to a certain extent. 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. Also note that the length = 0 call does not work after filling the list with the button. I am going to try to look for a pre-existing bug surrounding that issue now.
The previous comment may have to do with the TABLE element and not the SELECT element. Therefore I am unsure how to report. (new bug?)
report as new bug, and the part of seeting the array to zero is a known bug: 20875
Done. Bug: 21834: SELECT not sizing correctly inside a TABLE
Status: RESOLVED → VERIFIED
Ok, marking this bug verified with W98 build of 1999121508. Various other issues will be split off into new bugs.
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...
I verify this as well, but there is one slight problem. The pull-down arrow still does not always show up at the far right of the widget, it is sometimes various distances inside the select box. I'm working on figuring out a test case, I think it has something to do with multiple embedded tables. Could someone email me the bug numbers of the issues that have split off? Thanks.
This appears to be a problem with combining defined widths and percentages at the same time. It works if you define the second TD to 100% as well as the SELECT.
Please ignore my last comments they were intended for bug #21834. I have re-reference this attachment there, so please do not delete the attachment. Feel free to delete these last comments if possible and _sorry for the spam_!
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: