Closed Bug 1362907 Opened 7 years ago Closed 4 months ago

option text in select element with min-height is top aligned instead of centered

Categories

(Core :: Layout: Form Controls, defect)

55 Branch
defect

Tracking

()

VERIFIED FIXED
125 Branch
Webcompat Priority P3
Tracking Status
firefox125 --- verified

People

(Reporter: karlcow, Assigned: emilio)

References

(Regressed 1 open bug)

Details

(Whiteboard: [webcompat], [wptsync upstream])

Attachments

(4 files, 3 obsolete files)

See the screenshot 
* Gecko Firefox left 
* WebKit Safari center
* Blink Opera right

This is a spin off the webcompat issue 
https://webcompat.com/issues/6475

I created a minimal test case on 
https://codepen.io/webcompat/pen/oWoQpG

select {
appearance: none;
-webkit-appearance: none;}
.min-height {min-height:50px;}

<select class="min-height">
  <option value="-1">Sélectionner</option>
  <option value="8" selected="">46</option>
 </select>


Expected: The text is vertically centered.
Actual: the text is align to the top.

This is happening only with min-height, when height is specified the alignment is vertically centered.
I'm not sure it's in Mats area for widget and moz-appearance.
Flags: webcompat?
Flags: needinfo?(mats)
Whiteboard: [webcompat]
This is happening both on Desktop and Android.
Attached file Testcase
I don't think this is related to 'appearance:none', the same issue also
occurs with native themeing.  I don't think this has ever worked correctly.

The first version that we vertically center the text in the 'height' case
is Firefox 31, before that we aligned both cases at the top.  We've never
centered the text for the 'min-height' case, AFAICT.
Flags: needinfo?(mats)
Not sure this is a similar case but we have a different alignment than WebKit and Blink. A combination of padding and height.
https://webcompat.com/issues/6669

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Webcompat Priority: --- → ?

See bug 1547409. Migrating whiteboard priority tags to program flags.

Webcompat Priority: ? → P3
Flags: webcompat?

This is also hitting select boxes at https://m.gsmarena.com, as per bug 1587082 (closed as dupe).

Severity: normal → S3
Attached file testcase 2

Just ran into this with Itiel when looking at a select in some Firefox frontend code, which happened to be deriving its height from min-height and had its contents misaligned as a result of this bug.

Here's a reduced testcase that I came up with while investigating.

ACTUAL RESULTS:
The first "Select" text is top-aligned within the select dropdown-button.

EXPECTED RESULTS:
That text should be vertically centered within its button, like all the other text.

Attachment #8865282 - Attachment description: select and text alignment → screenshot: select and text alignment
Attachment #9308877 - Attachment description: testcase 3 → testcase 2
See Also: → 1865557
Duplicate of this bug: 1865557
See Also: 1865557

Do a more special reflow, much like buttons etc do, in order to perform
vertical centering etc.

Do a more special reflow, much like buttons etc do, in order to perform
vertical centering etc.

Assignee: nobody → emilio
Status: NEW → ASSIGNED
Attachment #9365085 - Attachment is obsolete: true

emilio, please see the question in the patch :-)

Flags: needinfo?(emilio)

(In reply to Itiel from comment #13)

emilio, please see the question in the patch :-)

Yup yup, sorry for the lag. There are multiple possible approaches to this bug :)

This simplifies our combobox code a bit more:

  • Reflow() is only needed to compute the label isize.
  • Frame construction uses a setup more similar to <input type=file> to
    get the right frame tree, removing a bunch of special code.
  • Lots of special code removed all over the place.

I think comment 16 is an even better approach.

Flags: needinfo?(emilio)
Attachment #9388154 - Attachment description: Bug 1362907 - Make select use nsHTMLButtonFrame for layout. r=jfkthame,dholbert,#layout → Bug 1362907 - Make select use nsHTMLButtonControlFrame for layout. r=jfkthame,dholbert,#layout
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a75137d48b99
Make select use nsHTMLButtonControlFrame for layout. r=jfkthame,dholbert
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/44854 for changes under testing/web-platform/tests
Whiteboard: [webcompat] → [webcompat], [wptsync upstream]
Blocks: 1882752
Pushed by nfay@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/0deeb41b2f01
Avoid differences in menulist button position on android on a reftest.
Regressions: 1882802
Status: ASSIGNED → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → 125 Branch
Upstream PR merged by moz-wptsync-bot
Regressions: 1882854
Attachment #9388045 - Attachment is obsolete: true
Attachment #9369835 - Attachment is obsolete: true
Flags: qe-verify+

I've replicated this issue using Nightly 125.0a1 (2024-02-28) on Windows 10 x64 with the provided test cases.
Verified as fixed in the latest Firefox 125.0b4 version on Windows 10 x64, macOS 13, and Ubuntu 22.04, as the problem no longer occurs.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
Regressions: 1893177
Regressions: 1894168
Regressions: 1901764
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: