<select> listboxes have erroneous internal padding

NEW
Unassigned

Status

()

Core
Layout: Form Controls
P3
minor
11 years ago
5 years ago

People

(Reporter: Smokey Ardisson (offline for a while; not following bugs - do not email), Unassigned)

Tracking

({regression, testcase})

Trunk
regression, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [dbaron-1.9:Rf])

Attachments

(6 attachments)

Created attachment 266228 [details]
testcase

Since bug 381539, select widgets now have erroneous padding, as noted by smorgan in bug 381539 comment 1:

1) At the top and bottom of the list items and the scroll well
2) On the left and right of the list items

There's also an erroneous bevel/border (most noticeable at the bottom of the list); that might be bug 382040 or bug 382039, or it might be something else (I can file a separate bug if needed).

Note that these are regressions at least for Camino (except Camino had an erroneous 1 px padding at the top of the list that smfr was never able to eliminate).
Created attachment 266229 [details]
screenshot

Today's Minefield, Safari, Camino 1.5

Updated

11 years ago
Flags: blocking1.9?
Summary: <select> lists have erroneous internal padding → <select> listboxes have erroneous internal padding
Duplicate of this bug: 382385

Updated

11 years ago
Flags: blocking1.9? → blocking1.9+

Comment 3

11 years ago
Created attachment 278553 [details] [diff] [review]
fix v1.0

Part of this problem is that listboxes draw outside of their frame because HITheme wants the content box, not the box for the whole control. This patch fixes that problem, but we still have a weird clipping problem remaining.
Attachment #278553 - Flags: superreview?(pavlov)

Updated

11 years ago
Attachment #278553 - Flags: superreview?(pavlov) → superreview+

Comment 4

11 years ago
fix v1.0 landed on trunk, leaving this open for the clipping issue

Comment 5

11 years ago
Turns out the rest of this bug is cross-platform. I can see this exact same rendering problem with themed listboxes on Windows. There is a one-pixel-wide white lining drawn over the inside edge of the control. It obscures the left edge of the options and the right edge of the scrollbar and the top and bottom of both. I find it a little harder to see on Windows, but it is definitely there.
Assignee: joshmoz → nobody
Component: Widget: Cocoa → Layout: Form Controls
OS: Mac OS X → All
QA Contact: cocoa → layout.form-controls
Hardware: Macintosh → All

Updated

11 years ago
Severity: normal → major

Comment 6

11 years ago
Created attachment 278607 [details]
screenshot 2 (remaining layout bug)
So.. this worksforme on Linux.  Do you still see the problem if you disable native theming (using "-moz-appearance: none")?  Note that on Linux the white space is ONLY there if -moz-appearance is "listbox", and it does not overlap the option focus rect.  If I remove the -moz-appearance styling the white line goes away altogether.

This makes me think that this is at least partly a widget problem (esp. given it working on Linux).  In particular, I would start by looking at the padding and borders your theme code is giving the <select>.

As for the blocker, the initial blocking+ was for the bug as originally reported.  It's not clear to me that it applies to the remaining issue.  Especially since the Windows behavior has been as it is for years now, I bet.

Comment 8

11 years ago
GTK uses a different setup for listboxes - for example, it does not specify any border or padding (afaict, from reading through the code). Linux is the one impl that doesn't show this bug and I imagine there are any number of reasons that might be true. Can you debug on Windows or Mac?

Comment 9

11 years ago
On trunk linux with the native control (-moz-appearance: listbox) there is no white space between the options and the border of the control. I'm not sure what you're seeing. That white border not existing is probably part of the reason the bug doesn't show up on Linux.

I don't see this bug with Firefox 2 on Windows.

If I do -moz-appearance: none I don't see the bug on any platform, but like GTK that could be for any number of reasons. The border/padding is all different.

It would be best to debug this on a platform that does have the problem I think. I tried a bunch of native theme tweaking on Mac OS X and I can't get rid of the cropping.
> there is no white space between the options and the border of the control.

There is over here.  Might depend on your GTK theme.

> I don't see this bug with Firefox 2 on Windows.

Can you find a regression range?

> Can you debug on Windows or Mac?

On Windows, no.  On Mac, maybe, but not until I get back in mid-September.  Even then I wouldn't be able to spend more than a few hours a week on it.
Whiteboard: [dbaron-1.9:RuCo]
Whiteboard: [dbaron-1.9:RuCo] → [dbaron-1.9:Rf]

Comment 11

11 years ago
The remaining 1px problem is hardly a major bug.
Severity: major → minor
I think I don't see this on Mac anymore, but I can't be sure because I don't know what testcase Josh used to produce comment #6. Anyway as Håkan said, this is not blocking anymore.
Flags: blocking1.9+
I still see my comment 0 point 1 on my trunk build from last night; there's 1px of yellow between the top of the highlight (when the first item is selected) and top of the box (or bottom of the top border of the box, or however you want to describe it), and 1px of yellow between the bottom of the highlight (when the last item is selected) and the bottom of the box.  

You'll probably want to click elsewhere on the page to clear the nasty dotted focus ring when changing selections, since the ring+blue highlight+light yellow background+white bottom border makes the yellow harder to see there--or have a look with Pixie.

Comment 14

11 years ago
Created attachment 294003 [details]
testcase

this testcase makes it -maybe- easier to see the remaining issue

Comment 15

11 years ago
(In reply to comment #14)
> Created an attachment (id=294003) [details]
> testcase
> 
> this testcase makes it -maybe- easier to see the remaining issue


When the top or bottom list-item is selected (focussed) a 1px tall white space (or coloured space, if the select has a background applied) before or after the selected item is visible.
This comes from this rule in forms.css:
select[size],
select[multiple],
select[size][multiple] {
  /* Different alignment and padding for listbox vs combobox */
  vertical-align: text-bottom;
  padding: 1px 0 1px 0;
  -moz-appearance: listbox;
}

That strip of space does not exist in WebKit/Safari (it does exist in Fx 2/Gecko 1.8.1, though). I don't have a windows or linux box at hand to verify what happens there.
I believe that padding is there quite on purpose; you might want to look at the checkin history for the reasons for it, if any....  Also note that this is not what the bug was about to start with as far as I can tell (explicitly mentioned as being there in comment 0).
Fair enough; I got confused over what comment 5 et seq. were talking about and then didn't re-read my comment 0 closely enough :(

Let's call this one FIXED, then, and we can open a new box on eliminating that spurious 1px at least on Mac OS X, where it looks out-of-place.

Comment 18

9 years ago
Created attachment 359736 [details]
padded select box testcase

Is this bug only for multiple select objects?

I'm having problem with padding in a select box adds white space around the drop-down button. I would expect it to be added inside the box as in a multiple select box, and the drop-down button to be stretched (as with width/height).

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090129 Shiretoko/3.1b3pre
This bug is only about listboxes, and only with the default styling.  If you have an issue with a combobox when certain styles are applied, please file a new bug if there isn't a bug covering it already.  Note that application of CSS to form controls is undefined, for what it's worth.
You need to log in before you can comment on or make changes to this bug.