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

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Karl Dubost💡 :karlcow]

Attachment: screenshot: select and text alignment

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.

Comment 1

[Karl Dubost💡 :karlcow]

I'm not sure it's in Mats area for widget and moz-appearance.

Comment 2

[Karl Dubost💡 :karlcow]

This is happening both on Desktop and Android.

Comment 3

[Mats Palmgren (inactive)]

Attachment: 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.

Comment 4

[Karl Dubost💡 :karlcow]

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

Comment 5

[Firefox Bug Husbandry Bot]

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

Comment 6

[Firefox Bug Husbandry Bot]

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

Comment 8

[Thomas Wisniewski [:twisniewski]]

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

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: 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.

Comment 11

[Emilio Cobos Álvarez [:emilio]]

Attachment: WIP: Bug 1362907 - Don't make nsComboboxControlFrame a block. r=#layout

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

Comment 12

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1362907 - Don't make nsComboboxControlFrame a block. r=#layout

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

Comment 13

[Itiel]

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

Comment 14

[Emilio Cobos Álvarez [: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 :)

Comment 15

[Emilio Cobos Álvarez [:emilio]]

Attachment: WIP: Bug 1362907 - Use align-content: center to implement <select>.

Comment 16

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1362907 - Make select use nsHTMLButtonControlFrame for layout. r=jfkthame,dholbert,#layout

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.

Comment 17

[Emilio Cobos Álvarez [:emilio]]

I think comment 16 is an even better approach.

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a75137d48b99
Make select use nsHTMLButtonControlFrame for layout. r=jfkthame,dholbert

Comment 19

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/44854 for changes under testing/web-platform/tests

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2f259801220c
Fix a couple crashtests.

Comment 21

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0deeb41b2f01
Avoid differences in menulist button position on android on a reftest.

Comment 22

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/a75137d48b99
https://hg.mozilla.org/mozilla-central/rev/2f259801220c
https://hg.mozilla.org/mozilla-central/rev/0deeb41b2f01

Comment 23

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 24

[Ina Popescu, Desktop QA]

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.