1502233 - select element regressed. text alignment behaves differently in Firefox and Chrome on twitter

Status: RESOLVED DUPLICATE of bug 1501908

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

Description

[Karl Dubost💡 :karlcow]

Attachment: chrome left, firefox right

This is a spin off of https://webcompat.com/issues/20347
This seems to be a regression. I will run a mozregression.


Here a test case
https://codepen.io/webcompat/pen/jeXJLV

<p>simple default</p>
<select name="" id=""><option value="text">text is centered</option></select>
<p>padding 5px</p>
<select name="" id="" style="padding:5px"><option value="text">text is centered</option></select>
<p>padding 5px + height 20px</p>
<select name="" id="" style="padding:5px;height:20px"><option value="text">text is centered</option></select>

See the screenshot

Comment 1

[Karl Dubost💡 :karlcow]

not a regression as far as I can tell. This is happening on Firefox 62 to Firefox 65

Comment 2

[Karl Dubost💡 :karlcow]

ah it depends, there is another combination of things. Probably

This one shows a regression.

1. Go to https://twitter.com/search?f=videos&vertical=news&q=%22Joe%20Biden%22&src=tren
2. Open search filter 
3. check the alignment.

This is the regression range and indeed it touches select
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=b2fa4b07f6f7e489047808bd0238301ea943b4b3&tochange=ea09443dac2888f8c9f72964f907ccdb66e9960d


So now on my test case, this is something which predates this.
Let's add mats to the fray.

Comment 3

[Karl Dubost💡 :karlcow]

So for the twitter case which is the initial report, 63 is unaffected. 
for my test case, even 62 is affected.

Comment 4

[Karl Dubost💡 :karlcow]

We might need to separate another issue for the behavior difference exhibited in 
https://codepen.io/webcompat/pen/jeXJLV

Comment 5

[Karl Dubost💡 :karlcow]

The more generic case looks like this too.
https://webcompat.com/issues/6669

Comment 6

[Mats Palmgren (inactive)]

I don't have an account on Twitter, nor Tumblr.  Can you check if they use 'line-height'?
If so, the recent regression is likely a dupe of bug 1501908.

The difference in handling padding has been there for a long time as you noted.

Comment 7

[Mats Palmgren (inactive)]

FYI, there are Try builds available with that fix here:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=e1757e5a55b5b0d8fee0c857d94fb2eae004f4f4

Comment 8

[Mats Palmgren (inactive)]

> I don't have an account on Twitter, nor Tumblr.  Can you check if they use 'line-height'?

I'm also interested in the complete CSS rule they use to style that <select> if anyone can dig that up.  Thanks.

Comment 9

[Emilio Cobos Álvarez (:emilio)]

I do have a twitter account, the rules are (from most to least specific, that is, in the order devtools show them):

.SidebarFilterModule-filters .SidebarFilterModule-select {
    display: block;
    margin-left: -4px;
    width: 257px;
}
.t1-select, input[type="file"] {
    height: 30px;
    line-height: 30px;
}
input, textarea, div[contenteditable], .t1-select {
    display: inline-block;
    width: 210px;
    padding: 4px;
    margin: 0;
        margin-left: 0px;
    outline: 0;
    background-color: #fff;
    border: 1px solid #e6ecf0;
    border-radius: 3px;
}
.t1-label, input, textarea, div[contenteditable], .t1-select {
    margin: 0;
    font-size: 14px;
    line-height: 20px;
}
button, select {
    text-transform: none;
}
button, input, optgroup, select, textarea {
    color: inherit;
    font: inherit;
    font-size: inherit;
    line-height: inherit;
    margin: 0;
}

So it's a themed select (keeps the menulist appearance), and your recent patch should fix that, I'd think.

Comment 10

[Karl Dubost💡 :karlcow]

fwiw, this reproduce without an account. :)
Thanks emilio for the CSS.
and yes they use line-height. 
And removing the line-height fixes the issue on Firefox too without changing Chrome behavior.

Comment 11

[Mats Palmgren (inactive)]

Yikes, those CSS rules are horrible!  Does these people not realize that
many users actually change their preferred font size in the browser's
Preferences?  Can we please ask them to remove all explicit 'height' and
'line-height' declarations?  Those are not needed and are user hostile.

'font-size: 14px' is also completely unnecessary.  The font-size for
<input> etc are already slightly smaller than the font-size for text in
browsers by default.  If they really feel like they must set a font-size
they should use keywords instead of hard-coding 'px' sizes that some
people simply can't read because it's too small.
https://developer.mozilla.org/en-US/docs/Web/CSS/font-size#Formal_syntax
(i.e. smaller/larger/small/large etc...)

It makes me sad to see such rookie mistakes on a well-known site
like Twitter. :(

Comment 12

[Mats Palmgren (inactive)]

Should be fixed by bug 1501908.