User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.141 Safari/537.36

Steps to reproduce:

Display select element on Firefox 98.0.2.

Actual results:

The width of the element is different between Firefox 97.0.2 and 98.0.2.
98.0.2 is wider than 97.0.2 because of select element has right-padding between option text and selection arrow.

I try to clear appearance by code below;

<select>
<option>Item1</option>
<option>Item2</option>
<option>Item3</option>
</select>

<style>
select {
appearance: none;
-moz-appearance: none;
-webkit-appearance: none;
}
</style>

But Firefox 98.0.2 has right side padding yet. I cannot remove the padding, unlike Firefox 97.0.2 can remove it.

Expected results:

It should be better that the appearance is same between 97 and 98.
It also should be able to remove appearance.

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Form Controls' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

I see a similar change on macOS. This appears to have been caused by bug 1744009. Emilio, can you take a look?

I don't see this on Linux, that's a bit weird. Will look into Win/macOS tho.

Ah, Jonathan, do you have "always show scrollbars" set on macOS? I wonder if that explains the difference (scrollbars are overlay by default on GTK nowadays). I can see that on GTK, but only if I have non-overlay scrollbars.

Gah, I accidentally inverted the condition in https://hg.mozilla.org/integration/autoland/rev/78130d73ca75#l24.652 and we didn't have a test for it :(

In bug 17440091 I changed some code that looked like:

• Get the dropdown frame intrinsic size.
• If there's overlay scrollbars, add the non-overlay scrollbar size.

That code came from bug 869314. I misread the "if there's overlay
scrollbars" bit.

There's no need to explicitly add the scrollbar width to the intrinsic
size anymore. The dropdown frame no longer exists, and the button size
is split out from the scrollbar size nowadays. There's no reason
to artificially add any size to the content frame.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #6)

Ah, Jonathan, do you have "always show scrollbars" set on macOS?

Indeed, I do.

Looks like you've tracked this down - great, thanks!

Comment on attachment 9270708 [details]
Bug 1762873 - Don't incorrectly add scrollbar size to select intrinsic size. r=jfkthame

Beta/Release Uplift Approval Request

• User impact if declined: Potentially broken layouts.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: Open test-case and confirm that old behavior is restored.
• List of other uplifts needed: none
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Removes a piece of code that's no longer needed.
• String changes made/needed: none

https://hg.mozilla.org/mozilla-central/rev/bd4c36e21201

Comment on attachment 9270708 [details]
Bug 1762873 - Don't incorrectly add scrollbar size to select intrinsic size. r=jfkthame

Approved for 100.0b2.

https://hg.mozilla.org/releases/mozilla-beta/rev/07e83ce5091b

Set release status flags based on info from the regressing bug 1744009

Reproduced the appearance issue on Win10x64 using builds 97.0.2 and 98.0.2.
Verified that appearance is same between 97 on Win10/Mac 10.13 /Ubuntu 20.4 using Beta 100.0b2(20220405224846) and 101.0a1(20220406190321).