Open
Bug 285367
Opened 19 years ago
Updated 2 years ago
<select> with size="" renders as a listbox
Categories
(Core :: Layout: Form Controls, defect, P3)
Core
Layout: Form Controls
Tracking
()
NEW
People
(Reporter: moz, Unassigned)
Details
(Keywords: testcase)
Attachments
(2 files, 2 obsolete files)
<select size=""> is rendered as a text field instead of a popup menu, though clicking on it still pops up the proper menu. This can be fixed by adding |select[size=""]| as a selector to the rulesets for |select[size="0"], select[size="1"]| in forms.css.
Reporter | ||
Comment 1•19 years ago
|
||
Reporter | ||
Updated•19 years ago
|
Keywords: testcase
Summary: <select> with size="" rendered as a text field. → <select> with size="" renders as a text field.
Comment 2•19 years ago
|
||
is this a regression?
Reporter | ||
Comment 3•19 years ago
|
||
I'm actually not sure. The |size| attribute is supposed to be non-empty and an integer if used, and so it's not very common to see this (I've only run across it on one site that I can remember).
Comment 4•19 years ago
|
||
Is this fixable by 1.0? Or rather, should this be fixed by then? (Or even 0.9?...)
Reporter | ||
Comment 5•19 years ago
|
||
Yes. Want a patch? ;)
Reporter | ||
Comment 6•19 years ago
|
||
Patch for the fix I mentioned in comment 0. This also changes the non-Cocoa widget declaration, but I think that is the right thing to do (and shouldn't break anything anyway).
Assignee: pinkerton → mozilla
Status: NEW → ASSIGNED
Reporter | ||
Comment 7•19 years ago
|
||
I just checked Firefox; it doesn't suffer from this bug, so if the first part of the patch (the non-Cocoa widget bit) should be taken out, it can be.
Reporter | ||
Comment 8•19 years ago
|
||
Comment on attachment 178865 [details] [diff] [review] Patch for forms.css. Checked again; leaving it in doesn't break anything. Asking for review (or just super, considering the tiny size of the patch).
Attachment #178865 -
Flags: superreview?
Attachment #178865 -
Flags: review?
Reporter | ||
Comment 9•19 years ago
|
||
Upon further inspection, it looks like firefox (and un-themed Gecko?) totally disregards the -moz-appearance for selects, rendering them as popups if the resulting size is 1, and as listboxes otherwise. The patch still fixes selects with size="" for Camino, though it's probably not optimal. :/
Reporter | ||
Comment 10•19 years ago
|
||
This might be able to be fixed through forms.css using :not(), actually...
Reporter | ||
Comment 11•19 years ago
|
||
(In reply to comment #10) > This might be able to be fixed through forms.css using :not(), actually... Eh, should probably be fixed in code anyway. <select>s with size="" render at a funny height.
Can this be rolled in to the tweaking in bug 298111?
Reporter | ||
Comment 13•19 years ago
|
||
(In reply to comment #12) > Can this be rolled in to the tweaking in bug 298111? I think FF deals with this in code; I don't know if all cases can be overcome in CSS alone. (I should probably give up this bug, too.)
Comment 14•19 years ago
|
||
ping!
Severity: minor → normal
Priority: -- → P3
Target Milestone: --- → Camino1.0
Comment 15•19 years ago
|
||
Attachment #176801 -
Attachment is obsolete: true
Comment 16•19 years ago
|
||
The problem here seems to be that we when using nsNativeTheme, we choose which appearance to draw the widget in based on the "mAppearance" member of the nsStyleDisplay struct, which comes out of CSS. But when using gecko widgets, there is logic in nsCSSFrameConstructor that figures out how to draw the select based on the "size" attribute. So either we replicate the logic in nsCSSFrameConstructor::ConstructSelectFrame() via CSS, or this needs a more thorough fix in layout.
Comment 17•19 years ago
|
||
The problem is that in CSS (at least the part we implement) you can't select on "attribute value is a number". Which is what I believe we'd need here.
Comment 18•19 years ago
|
||
(In reply to comment #17) > The problem is that in CSS (at least the part we implement) you can't select on > "attribute value is a number". Which is what I believe we'd need here. So this isn't fixable for us without changing code, correct? Is there a core bug corresponding to fixing this or should this be moved to widgets:mac and fixed on the trunk? (i.e. is there anything we can do to fix this by 1.0 on the Gecko 1.8 branch?)
Comment 19•19 years ago
|
||
> So this isn't fixable for us without changing code, correct?
I suspect that is correct.
Comment 20•19 years ago
|
||
(In reply to comment #19) > > So this isn't fixable for us without changing code, correct? > > I suspect that is correct. > Because this will require a code change which I doubt we'll get on the 1.8 branch (possibly on 1.8.1 though), I'm retargeting this bug for 1.1.
Target Milestone: Camino1.0 → Camino1.1
Reporter | ||
Comment 21•19 years ago
|
||
This shouldn't be assigned to me anymore; it's a bigger change than I thought at first.
Assignee: mozilla → mikepinkerton
Status: ASSIGNED → NEW
Comment on attachment 178865 [details] [diff] [review] Patch for forms.css. obsoleting this patch since it needs a code fix, too
Attachment #178865 -
Attachment is obsolete: true
Attachment #178865 -
Flags: superreview?
Attachment #178865 -
Flags: review?
Assignee: mikepinkerton → nobody
QA Contact: form.controls
Target Milestone: Camino1.1 → Camino2.0
Comment 23•17 years ago
|
||
Moving to Cocoa Widgets, since this happens in post-CSS-removal Camino
Assignee: nobody → joshmoz
Component: HTML Form Controls → Widget: Cocoa
Product: Camino → Core
QA Contact: form.controls → cocoa
Target Milestone: Camino2.0 → ---
Comment 24•17 years ago
|
||
I can reproduce with current Linux trunk, marking as a cross-platform layout bug.
Assignee: joshmoz → nobody
Component: Widget: Cocoa → Layout: Form Controls
Flags: blocking1.9?
OS: Mac OS X → All
QA Contact: cocoa → layout.form-controls
Hardware: Macintosh → All
Comment 25•17 years ago
|
||
I don't think they are rendering as text fields though - they are rendering as funny-looking listboxes with only one option, no scrollbar. That is still incorrect, they should be the same as size="1" selects.
Summary: <select> with size="" renders as a text field. → <select> with size="" renders incorrectly as funny looking listbox
Comment 26•17 years ago
|
||
Note that theming impls that care could fix this by making ThemeSupportsWidget return false in cases like this... It'd look a little weird, but not as weird as it does now. If someone wants to fix it, the options as I see them are to either have another CSS selector for this or to move the appearance rule into C++ wholesale (e.g. in nsHTMLStylesheet). David, do you hve a preference between those two or other ideas?
Summary: <select> with size="" renders incorrectly as funny looking listbox → <select> with size="" renders as a text field.
Updated•17 years ago
|
Summary: <select> with size="" renders as a text field. → <select> with size="" renders as a listbox
Comment 27•17 years ago
|
||
If I put "-moz-appearance: none;" on all the controls this bug does go away. However, a different problem seems to still exist. Why are the selects with bogus size values taller than the select with 'size="1"'?
Comment 28•17 years ago
|
||
Comment 29•17 years ago
|
||
Because the forms.css rules give listboxes 1px of top and bottom padding (which you've complained about in another bug) and then remove that padding for comboboxes. So if the node doesn't match the combobox rule, the padding will still be there. Given that, sounds like a special selector is what we might want here...
Flags: blocking1.9? → blocking1.9-
Whiteboard: [wanted-1.9]
Updated•17 years ago
|
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
Flags: wanted1.9-
Flags: wanted1.9+
Flags: wanted-next+
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•