1526855 - select is wide when the label is wide in optgroup (not on Chrome)

Status: RESOLVED WORKSFORME

(Core :: Layout: Form Controls, defect, P3)

Description

[Karl Dubost💡 :karlcow]

Attachment: top firefox, middle chrome, bottom safari

1. Go to https://codepen.io/webcompat/pen/OdvawJ
   with Firefox, Chrome and Safari last nightly editions.

Firefox maximize to the length of the label text.
This breaks layout on small viewport like in https://webcompat.com/issues/25569

notice how the width of the widget is different in between browsers.

<select>
<optgroup label="aaaaaaaaaaaaaaaaaaaaaa"></optgroup>
<option value="en-CA">1</option>
<option selected="" value="fr-CA">2</option>
</select>

Comment 1

[Cameron McCormack (:heycam)]

Simon, where should intrinsic sizing of <select> elements needing to ignore <optgroup>s be defined? Is that something your work covers?

Comment 2

[Cameron McCormack (:heycam)]

And that's really just the contribution of the <optgroup>'s label that needs to be ignored. If the <optgroup> is wrapping some <option>s, those <option>s need to contribute to the intrinsic size calculations. (What about margin/padding/borders on the <optgroup> itself? Not sure, didn't test...)

Comment 3

[Simon Pieters [:zcorpan]]

This would be https://html.spec.whatwg.org/multipage/rendering.html#width-of-the-select's-labels

I hope to be able to work on form control rendering stuff some time in Q2, and if so I can look into this. It seems like an easy fix for the spec and can be tested with a reftest or even a testharness.js test.

Can you file an issue in whatwg/html?

Comment 4

[Cameron McCormack (:heycam)]

Thanks, filed https://github.com/whatwg/html/issues/4502.

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 7

[Dennis Schubert [:denschub]]

This appears to be no longer an issue.