1405085 - select elements lose native appearance under certain conditions

Status: RESOLVED WORKSFORME

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

Description

[staleydyla.n]

Attachment: Screen Shot 2017-10-02 at 11.52.25 AM.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20170925150345

Steps to reproduce:

Visit facebook.com while logged out.


Actual results:

<select> elements are rendered using a non-native appearance.


Expected results:

<select> elements should be rendered in a similar manner to Chrome and Safari

Comment 1

[Jet Villegas (inactive)]

The <select> controls seem to be styled to look that way on Firefox. Compare to the same controls with default styling here:

http://media.junglecode.net/test/1405085/test.html

Comment 2

[Jet Villegas (inactive)]

This site depends on -webkit-appearance:menulist-button;

Comment 3

[Karl Dubost💡 :karlcow]

Attachment: select on firefox left, chrome right

Probably something related 
https://webcompat/issues/10773

See https://codepen.io/webcompat/pen/dVZGxG

Select once styled is quite ugly compared to other platforms.

Comment 4

[Karl Dubost💡 :karlcow]

https://webcompat/issues/10773 -> https://webcompat.com/issues/10773

Comment 5

[staleydyla.n]

This also occurs when you apply a border-radius to a <select> element, so I'm not sure -webkit-appearance is the root cause.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

So in Gecko we don't draw native theme border/background when there are author-level styles of border or background properties.   So there are potentially a few issues here:
 * do other browsers do similar, but then not do that if there's also an author-level appearance/-webkit-appearance declaration?
 * do we need to update our non-native-theme select styles to look more like those in other browsers?
 * do we need to add support for another -webkit-appearance value here?

Comment 7

[Karl Dubost💡 :karlcow]

Attachment: Firefox left, Safari center, Chrome right

About David Baron first question:

>  * do other browsers do similar, but then not do that 
>    if there's also an author-level appearance/-webkit-appearance 
>    declaration?


They do draw the widget and the content. Firefox behaves differently.
(This was tested in the latest version of each desktop browser on macos as of this date)

If someone could test Edge, that would be greatly appreciated.
https://codepen.io/webcompat/pen/rGQYae


> * do we need to update our non-native-theme select styles 
>   to look more like those in other browsers?

There are differences in between Chrome and Safari, but these differences are less striking than in Firefox. So probably yes, not necessary copy entirely but get closer.

> * do we need to add support for another -webkit-appearance value here?

This is probably Bug 1368555

Comment 8

[Thomas Wisniewski]

Attachment: edge.png

(In reply to Karl Dubost :karlcow from comment #7)
> If someone could test Edge, that would be greatly appreciated.
> https://codepen.io/webcompat/pen/rGQYae

Here's what they look like on Edge 15 on the Quantum reference hardware.

Comment 9

[Karl Dubost💡 :karlcow]

https://webcompat.com/issues/13311
is probably something related to this issue. 

And it creates a webcompat issue with Chrome. 

(footnote Pale Fire style: The rendering is also far to be nice in Safari too. They seem to have tested only in Chrome. Still the behavior of Chrome is more consistent with what someone could expect.)

Comment 10

[Ksenia Berezina [:ksenia]]

The linked webcompat bugs don't seem to be reproducible, so let's close this.