<select> with size="" renders as a listbox

NEW
Unassigned

Status

()

Core
Layout: Form Controls
P3
normal
13 years ago
8 years ago

People

(Reporter: Wevah, Unassigned)

Tracking

({testcase})

unspecified
testcase
Points:
---
Bug Flags:
wanted-next +
blocking1.9 -
wanted1.9 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

13 years ago
<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

13 years ago
Created attachment 176801 [details]
Testcase.
(Reporter)

Updated

13 years ago
Keywords: testcase
Summary: <select> with size="" rendered as a text field. → <select> with size="" renders as a text field.
is this a regression?
(Reporter)

Comment 3

13 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).
Is this fixable by 1.0? Or rather, should this be fixed by then?

(Or even 0.9?...)
(Reporter)

Comment 5

13 years ago
Yes. Want a patch?

;)
(Reporter)

Comment 6

13 years ago
Created attachment 178865 [details] [diff] [review]
Patch for forms.css.

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

13 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

13 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

13 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

13 years ago
This might be able to be fixed through forms.css using :not(), actually...
(Reporter)

Comment 11

13 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

13 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

12 years ago
ping!
Severity: minor → normal
Priority: -- → P3
Target Milestone: --- → Camino1.0

Comment 15

12 years ago
Created attachment 198769 [details]
Testcase with select with bogus size.
Attachment #176801 - Attachment is obsolete: true

Comment 16

12 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.
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.
(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?)
> So this isn't fixable for us without changing code, correct?

I suspect that is correct.
(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

12 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

11 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

10 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

10 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.

Updated

10 years ago
Summary: <select> with size="" renders as a text field. → <select> with size="" renders incorrectly as funny looking listbox
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.
Summary: <select> with size="" renders as a text field. → <select> with size="" renders as a listbox

Comment 27

10 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

10 years ago
Created attachment 279141 [details]
testcase with -moz-appearance: none;
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]
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
Flags: wanted1.9-
Flags: wanted1.9+
Flags: wanted-next+
You need to log in before you can comment on or make changes to this bug.