The initial attempt at supporting [-webkit-]appearance (bug 1333482) failed miserably because it's simply not web-compatible in the way we first thought and how the CSS UI spec describes it. I now believe that in order to be web-compatible we must implement the *full* set of -webkit-appearance values. Here's one list I've found: https://developer.apple.com/library/content/documentation/AppleApplications/Reference/SafariCSSRef/Articles/StandardCSSProperties.html#//apple_ref/doc/uid/TP30001266-_webkit_appearance We should also NOT support the unprefixed appearance property unless Chrome/Safari also does so first, because doing so unilaterally will inevitably lead to web-compat issues. I think it's probably best to make -moz-appearance an alias for -webkit-appearance (or vice versa), and then add the missing -webkit-appearance keywords that we don't yet have.

I note that an earlier attempt at aliasing was backed out in bug 1249134. The reason given was "-webkit-appearance:none works differently on checkbox/radio controls". However, we have now fixed that in bug 605985. Daniel/Mike do you recall if there were other incompatibilities?

Making bug 1349835 dependent on this one since we need to make sure if anything other than input type checkbox causes any accessibility curn. Mats' WIP patch in there fixes the bug in case of appearance: none;. Just want to make sure we track all of this in sync.

I'll try to document all the cases I meet/met (new and old). leroy-merlin - mobile site https://webcompat.com/issues/7064 https://codepen.io/webcompat/pen/awzPbw relies on select { -webkit-appearance: initial; } to remove the widget, aka default to -webkit-appearance: none;

Only -webkit-appearance: none is provided. This is the most common case. https://webcompat.com/issues/7091 #LANG_FORM select { -webkit-appearance: none; } The fix we can usually recommend is: provide -moz-appearance: none;

-webkit-appearance: none and appearance: none are provided. https://webcompat.com/issues/7524 for the site bet365.com on mobile ```css .mmm-PreferencesRow_List { width: 100%; border: 0; background-color: #ddd; font-size: 15px; color: #666; line-height: 20px; padding: 22px 11px 7px; margin-top: -22px; background-clip: content-box; -webkit-appearance: none; appearance: none; } ```

Same than previous comment -webkit-appearance: none and appearance: none are provided. https://webcompat.com/issues/7612

https://webcompat.com/issues/7760 -webkit-appearance: none and background image. ```css .selects-container select { margin: 0; border-radius: 3px; -moz-border-radius: 3px; -webkit-border-radius: 3px; width: 130px; padding-left: 10px; -webkit-box-sizing: border-box; -moz-box-sizing: border-box; -webkit-appearance: none; box-sizing: border-box; height: 40px; color: #a2a2a2; font-size: .9em; font-weight: normal; overflow: hidden; background: url(../images/website/select-arrows.svg) no-repeat 115px 12px #282828; border: 0; } ```

https://webcompat.com/issues/1006#issuecomment-181161213 https://codepen.io/anon/pen/QyJMGx about -webkit-appearance: button and background-image invisible on Gecko. #areaNavi select { … -webkit-appearance: button; -moz-appearance: button; appearance: button; … background: url("/iphone/img/icon_sort.png") no-repeat scroll 100% 50% transparent !important; background-size: 7px 9px !important; … } On WebKit and Blink, "-webkit-appearance: button" becomes "none". To note that the default select is "-webkit-appearance: menulist-button" On Gecko, the -moz-appearance: button is a button and so the image is not displayed. To note that the default select is "-moz-appearance: menulist" (the site has changed design since)

Similar to the previous comment from https://webcompat.com/issues/1005#issuecomment-120774729 div.domModule table td select { … background-color: transparent; background-position: 97% 50%; … -webkit-appearance: button; -moz-appearance: treeitem; appearance: button; background-image: url(/common/img/bg_dom_select_arw.png); background-repeat: no-repeat; background-size: 14px 14px; -webkit-background-size: 14px 14px; } people seems to use -webkit-appearance: button without realizing that it means -webkit-appearance: none while -moz-appearance: button or treeitem in this case is working.

Other cases have been documented on https://groups.google.com/d/msg/mozilla.dev.platform/oZ9cPF8Y1pE/LiSUtpeHBwAJ

See also https://bugzilla.mozilla.org/show_bug.cgi?id=1357655 about -webkit-appearance: inherit.

In the current state of YouTube. This is a case where `-webkit-appearance: none` will break things once implemented in Firefox. https://webcompat.com/issues/8034#issuecomment-326163969 putting it here as a reminder.

input[type="checkbox"] { background-image: url("https://ir.ebaystatic.com/rs/v/u4v4rbewii4nxcrsboppckq4520.png"); background-position: -28px -2px; background-attachment: scroll; background-size: auto 33px; background-clip: border-box; background-origin: padding-box; background-repeat: no-repeat; border-width: 0; height: 32px !important; margin-left: 5px; margin-right: 0; vertical-align: middle; width: 32px !important; display: table-cell; -webkit-appearance: none; padding: 16px; box-sizing: border-box; background-color: initial; }

Hi mats, Since bug 605985 and bug 1352238 are fixed, I think we are good to make -webkit-appearance an alias for -moz-appearance (or vice versa) first? Or is there any other concerns that I miss to take into account?

I don't think it's possible to blindly alias -webkit-appearance with -moz-appearance, except for the none value. Also note that there's work going on Chrome side to determine which values they could drop. https://bugs.chromium.org/p/chromium/issues/detail?id=767757 In September 2017, with Mike and Eric, we check all the combinations and their behavior and it's a bit hectic. * form elements * vs style attributes -webkit-appearance / -moz-appearance * with variation of borders and background See https://miketaylr.com/bzla/webkit-appearance.html Our WebCompat position (extracted from our threads about the topic): * Removing -moz-appearance is an issue. * Sometimes the CSS cascade doesn't help resolving the web compatibility issue. * -webkit-appearance: none is the top priority (with side effects related to background and border) * Go step by step to implement/allow other values for -webkit-appearance. Rinse and Repeat.

Here's a portion of an email reply I sent a few weeks back that is relevant to the idea of aliasing (vs removing): > The only question I have is if we should remove -moz-appearance (for web > content) or if we should expose it as an alias for -webkit-appearance. > (Whichever breaks the web the least has my vote.) I think removing -moz-appearance is problematic. It's not uncommon for popular sites to serve different stylesheets to different browsers (based on UA strings). Aliasing might be possible, with some kind of intelligent mapping between similar-ish values. This would also possibly fix the issue where sites server different values for -moz-appearance and -webkit-appearance[1]: [1] https://webcompat.com/issues/1005#issuecomment-120774729 div.domModule table td select { [...] -webkit-appearance: button; -moz-appearance: treeitem; appearance: button; background-image: url(/common/img/bg_dom_select_arw.png); [...] } I suppose the alternative is supporting both, but preferring -webkit-appearance (breaking the cascade...). Note: we don't have evidence that this pattern is wide-spread. But it's non-theoretical, and possibly something that could be researched via HTTP archive or similar. Whatever we decide, some time baking in non-release builds would be good to see what gets fixed and what pops up as site bustage. > Fwiw, implementing the extra -webkit-appearance values shouldn't be much > work (I think). I've looked at them briefly and they appear to be > slight style/behavior-variations of well-known controls. If they could be aliased to well-known controls, or a single "base" value, that seems reasonable, perhaps. > The important thing is to *recognize them as valid values* to avoid > using a value from some other rule, which is what causes web-compat > issues. If they look/behave exactly as in Chrome is unimportant as long > as they are usable; for example, we could implement 'square-button' as > an alias for 'button'. Here's a test page with the known values https://miketaylr.com/bzla/webkit-appearance.html. Most of them are nonsense (and some are sensitive to border/bg image properties -- see the toggle buttons on the top right). FWIW, the latest Edge Mobile only supports the following: -webkit-appearance: none on radio/checkbox suppresses the widget, and for <select> hides the dropdown arrow. <select> seems to be sensitive to more values and hides the dropdown. That's a good place to start a first implementation, I think. The majority of our bugs fall into the following categories: -webkit-appearance: none + bg/border to style a custom checkbox -webkit-appearance: none + bg/border (sometimes on parent elm) to style a custom select (so we end up painting 2 dropdown arrows....): e.g., see images @ https://webcompat.com/issues/7064 -webkit-appearance: button on select to hide the dropdown arrow (treated as none, at least if you look at computed style) Support for that would solve the majority compat cases.

(In reply to Mike Taylor [:miketaylr] (58 Regression Engineering Owner) from comment #17) > I think removing -moz-appearance is problematic. It's not uncommon for > popular sites to serve different stylesheets to different browsers (based on > UA strings). Fair enough. I guess we can do that as a separate bug later in any case. > I suppose the alternative is supporting both, but preferring > -webkit-appearance (breaking the cascade...). I think we should try with a regular alias to begin with. I'm hoping / expecting that will work out just fine. (i.e. make -webkit-appearance the property name, with -moz-appearance as an alias, so that we serialize to -webkit-appearance) > Here's a test page with the known values > https://miketaylr.com/bzla/webkit-appearance.html. Most of them are nonsense > (and some are sensitive to border/bg image properties -- see the toggle > buttons on the top right). Right, specifying some properties such as background / border turns off the native theme for some values of -moz-appearance: http://searchfox.org/mozilla-central/rev/d0448c970093f94bd986a21d3a9e8c366b316eb4/widget/nsNativeTheme.cpp#345-354 http://searchfox.org/mozilla-central/rev/d0448c970093f94bd986a21d3a9e8c366b316eb4/widget/windows/nsNativeThemeWin.cpp#2091-2100 http://searchfox.org/mozilla-central/search?q=HasAuthorSpecifiedRules This should probably be a separate investigation to see which properties does that, and for which -moz-/-webkit-appearance values in Firefox / Chrome. (This should probably be handled in a separate bug.) I think the initial step in this bug would be to understand what the values we don't currently support, but that Chrome supports, actually do in terms of rendering / behavior. Then we can decide if those need any work in layout, or if we can simply map them to existing controls (which I expect we can, with some minor tweaks perhaps).

BTW, I think we can ignore the scrollbar* values listed in https://developer.apple.com/library/content/documentation/AppleApplications/Reference/SafariCSSRef/Articles/StandardCSSProperties.html#//apple_ref/doc/uid/TP30001266-_webkit_appearance They don't seem to be supported as valid values in Chrome. Note also that the list in the above URL is incomplete. For example, <progress> has the value 'progressbar' in Gecko and 'progress-bar' in Chrome (sigh). We need to check what the initial value is for those newer HTML elements in Firefox vs. Chrome.

This might be a better reference of which values Chrome actually supports: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/ThemeTypes.h?sq=package:chromium&dr=C&l=48

https://webcompat.com/issues/12821 input[type="submit"],input[type="text"],input[type="password"] { -webkit-appearance:none; -webkit-border-radius:0; background-color:#fff } select { -webkit-appearance:none; -webkit-border-radius:0; background:#fff url(images/dropdown.gif) no-repeat right center; } .reevoo-select { -webkit-appearance:menulist; background-image:initial }

We have some use counters for the property values in Chromium: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/css/parser/CSSPropertyParserHelpers.cpp?l=1594 The results: https://www.chromestatus.com/metrics/feature/timeline/popularity/1351 https://www.chromestatus.com/metrics/feature/timeline/popularity/1352 https://www.chromestatus.com/metrics/feature/timeline/popularity/1353 https://www.chromestatus.com/metrics/feature/timeline/popularity/1354 https://www.chromestatus.com/metrics/feature/timeline/popularity/1355 https://www.chromestatus.com/metrics/feature/timeline/popularity/1356 https://www.chromestatus.com/metrics/feature/timeline/popularity/1357 https://www.chromestatus.com/metrics/feature/timeline/popularity/1358 https://www.chromestatus.com/metrics/feature/timeline/popularity/1359 https://www.chromestatus.com/metrics/feature/timeline/popularity/1360 https://www.chromestatus.com/metrics/feature/timeline/popularity/1361 https://www.chromestatus.com/metrics/feature/timeline/popularity/1362

I have investigated into the 51 -webkit-appearance values listed here https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/ThemeTypes.h?sq=package:chromium&dr=C&l=48 Basically, I just compare the attachment 8923730 [details] and attachment 8923732 [details] manually on Mac. And I think there are 24 media-* related values that Chrome don't (completed) support yet. For other 27 values, I list the results below respectively: "<--" means there is a -moz-appearance value that I think its rendering / behavior is similar enough to map to the value. "X" means Chrome supports the value but FF don't (or no any rendering / behavior of the -moz-appearance value is similar to it). "unsupported" means Chrome don't (completed) support the value yet. -webkit-appearance -moz-appearance none <-- none checkbox <-- checkbox radio <-- radio push-button X square-button <-- button-bevel button <-- button button-bevel unsupported inner-spin-button X listbox unsupported listitem unsupported menulist <-- menulist menulist-button X menulist-text unsupported menulist-textfield unsupported meter unsupported progress-bar unsupported progress-bar-value unsupported slider-horizontal <-- scrollbarthumb-horizontal slider-vertical <-- scrollbarthumb-vertical sliderthumb-horizontal <-- scale-horizontal sliderthumb-vertical <-- scale-vertical caret unsupported searchfield <-- searchfield searchfield-cancel-button X textfield unsupported textarea unsupported caps-lock-indicator unsupported Mats, what do you think about the result? So next step would be implement those values annotated as "X" so we could make -webkit-appearance the property name and -moz-appearance as an alias?

(In reply to Louis Chang [:louis] from comment #25) > -webkit-appearance -moz-appearance > push-button X Yes, add a new value and handle it as 'button' in widget code. push-button/button looks the same to me on both Linux/OSX in Chrome. > square-button <-- button-bevel Interesting, 'square-button' looks more like 'button' in Chrome *on Linux*, so we should probably also check that our -moz-appearance values looks reasonable across platforms and spawn off some bugs to fix any differences. In this case, our rendering on OSX seems more correct to me, so we should fix the rendering on Linux (make it "flat" look with 1px solid border). But yes, renaming our current button-bevel value to square-button seems like the right fix here. > button-bevel unsupported After renaming our button-bevel value to square-button, we can implement a new button-bevel value as in Chrome (which appears to have no background, no borders, no states; so should be trivial to implement in widget/) > inner-spin-button X Yes, we need to implement the rendering for this value (up+down arrow). I wonder if the native platforms have some support for it? > listbox unsupported 'listbox' is the default value for <select multiple> in Gecko (and Chrome), so I don't understand why you say this is "unsupported". I think we can map this value as is. > listitem unsupported Looks the same as Chrome button-bevel to me. Can we handle it the same? We might want to rename our current value -moz-listitem and then add a new listitem value if there's any difference to Chrome. > menulist-button X Looks similar to menulist. We can probably implement it by just falling in to menulist code. But since we already support menulist-button with a different rendering we probably need to preserve that for internal use. That is, rename our current menulist-button to -moz-menulist-button first, then add a new menulist-button that renders as menulist. (BTW, -moz-appearance:menulist-button already looks quite broken to me, e.g. <button style="-moz-appearance:menulist-button">Text</button> renders "Text" but no chevron on Linux, but suppress the text and only renders a chevron on OSX. That seems like a bug to me.) > menulist-text unsupported > menulist-textfield unsupported It seems Chrome doesn't do anything special for these values in the testcase. They are parsed as valid values though. It seems the rendering of these values varies between platforms in Firefox. menulist-textfield has a chevron on OSX, but not on Linux for example. So we should probably rename our current values -moz-menulist-* and then add new menulist-text/textfield values to implement the Chrome rendering. > meter unsupported We should first rename our 'meterbar' value to 'meter', then add 'meterbar' as a synonym for 'meter' in the style system (map it to the same internal NS_THEME_METER computed value). > progress-bar unsupported We should first rename our 'progressbar' value to 'progress-bar', then add 'progressbar' as a synonym in the style system. > progress-bar-value unsupported It's not clear to me what this value does in Chrome. Is there an associated pseudo-element where it actually does something? If not, just add the value and make it behave as button-bevel. > slider-horizontal <-- scrollbarthumb-horizontal > slider-vertical <-- scrollbarthumb-vertical > sliderthumb-horizontal <-- scale-horizontal > sliderthumb-vertical <-- scale-vertical Rename our values to the -webkit-appearance values first, then add synonyms. > caret unsupported Add the value, handle it as 'button-bevel' in the widget code. > searchfield-cancel-button X We should implement this value, rendering a "X" cancel icon. > textfield unsupported > textarea unsupported Why can't we map these to our values? How is Chrome incompatible? > caps-lock-indicator unsupported This value doesn't seem to be a valid -webkit-appearance value in Chrome. I think we can skip it. (all the -internal-media-* values are also invalid in Chrome, so those should be removed from the testcase) > So next step would be implement those values annotated as "X" so we could > make -webkit-appearance the property name and -moz-appearance as an alias? Sounds good to me. We also need to fix the blocking bugs before this can be enabled. We should probably also triage older bugs about incompatible -webkit/-moz-appearance to make sure we don't miss something important. We also need to add the media-* values (but not the -internal- ones). We can make them all like button-bevel, i.e. do nothing in widget code. For documentation purposes, I think it's clearer if we refer to values that we do not currently support in -moz-appearance as "unsupported" (e.g. caret), and refer to values that we currently do support but that are incompatible with -webkit-appearance as "incompatible" (e.g. menulist-button) together with a detailed description of *how* it's incompatible. While implementing the above, I think it's important that we verify that the rendering in Firefox/Chrome is reasonably compatible on *all* our Tier-1 platforms (assuming that Chrome supports them). Please note that most of our users are on Windows, so that's probably the most important platform to test.

(In reply to Mats Palmgren (:mats) from comment #26) > > progress-bar-value unsupported > > It's not clear to me what this value does in Chrome. Is there an associated > pseudo-element where it actually does something? If not, just add the value > and make it behave as button-bevel. I found only two mentions on chromium https://bugs.chromium.org/p/chromium/issues/detail?id=87249 https://bugs.chromium.org/p/chromium/issues/detail?id=79596 And one in WebKit https://bugs.webkit.org/show_bug.cgi?id=40823 on macOS on Chrome Canary and Safari Tech Preview, they both seem to have no effect. https://codepen.io/anon/pen/ZaGNYr

Right, it appears to be associated with the ::-webkit-progress-value pseudo element: https://trac.webkit.org/wiki/Styling%20Form%20Controls We have a corresponding ::-moz-progress-bar pseudo(*) which has '-moz-appearance: progresschunk': http://searchfox.org/mozilla-central/rev/423b2522c48e1d654e30ffc337164d677f934ec3/layout/style/res/forms.css#859 so we might want to handle it as: -webkit-appearance -moz-appearance progress-bar-value <-- progresschunk (i.e. add the 'progress-bar-value' value and make 'progresschunk' a synonym in the style system) (*) our pseudo name seems a bit unfortunate since it might be mistaken to correspond to ::-webkit-progress-bar

> so we might want to handle it as: > progress-bar-value <-- progresschunk ... then again, perhaps not since it doesn't actually do anything in Chrome on other elements AFAICT, unlike our 'progresschunk'. So maybe we should just it handle it as 'button-bevel' for now. We can emulate it more closely if we decide to add aliases for the ::-webkit-* pseudos in the future.

For documentation and to make sure if I understand your points correctly? We can divide the values implementation into three groups: 1. existing -moz-appearance values that can directly map to -webkit-appearance values (no need to change) none checkbox radio button listbox menulist searchfield textfield textarea 2. existing -moz-appearance values but need different implementation button-bevel: rename to square-button and implement new button-bevel where its rendering/behavior is like Chrome listitem: rename to -moz-listitem and implement new listitem where its rendering/behavior is like new button-bevel menulist-button: rename to -moz-menulist-button and implement new menulist where its rendering/behavior is like menulist menulist-text: rename to -moz-menulist-textfield and implement new menulist-text where its rendering/behavior is like new button-bevel menulist-textfield: rename to -moz-menulist-textfield and implement new menulist-textfield where its rendering/behavior is like new button-bevel caret: change the implementation to make it render/behave like new button-bevel 3. new added -moz-appearance values push-button: use implementation of button square-button: rename from button-bevel, use implementation of old button-bevel inner-spin-button: implement inner-spin-button where its rendering/behavior is like Chrome -moz-listitem: rename from listitem, use implementation of old listitem -moz-menulist-button: rename from menulist-button, use implementation of old -menulist-button -moz-menulist-text: rename from menulist-text, use implementation of old menulist-text -moz-menulist-textfield: rename from menulist-textfield, use implementation of old menulist-textfield meter: rename from meterbar (add meterbar as a synonym for meter) progress-bar: rename from progressbar (add progressbar as a synonym for progress-bar) progress-bar-value: implement the value where its rendering/behavior is like new button-bevel searchfield-cancel-button: implement searchfield-cancel-button where its rendering/behavior is like Chrome slider-horizontal: rename from scrollbarthumb-horizontal slider-vertical: rename from scrollbarthumb-vertical sliderthumb-horizontal: rename from scale-horizontal sliderthumb-vertical: rename from scale-veritcal media-*(15): implement the values where their rendering/behavior are like new button-bevel

A picture of mapping table between -webkit-appearance and -moz-appearance. (Just ignore it if it doesn't make you clearer...)

(In reply to Louis Chang [:louis] from comment #25) > slider-horizontal <-- scrollbarthumb-horizontal > slider-vertical <-- scrollbarthumb-vertical I think these need more investigation. For example, slider-horizontal is the default value for <range> in Chrome, whereas we use '-moz-appearance: range'. > sliderthumb-horizontal <-- scale-horizontal > sliderthumb-vertical <-- scale-vertical These also need more investigation. The sliderthumb-* values appears to only render the thumb part (of a <range>?), whereas our scale-* is for the "bar part" (i.e. the background) of some part of our video controls? http://searchfox.org/mozilla-central/source/toolkit/themes/shared/scale.css#8 I'm guessing the above values maps to our range / range-thumb values respectively, except that we don't have any corresponding *-vertical values. Our rendering of the thumb is round so it works for both (at least on Linux, but please check other tier-1 platforms). We should probably implement rendering for slider-vertical at some point, but I don't see it as blocking this bug. So, we should probably just rename our range / range-thumb values to slider-horizontal / sliderthumb-horizontal, and add synonyms for the old values. Also add the new *-vertical values as distinct values, but map them internally in widget code to the *-horizontal code paths for now.

(In reply to Louis Chang [:louis] from comment #30) > 1. existing -moz-appearance values that can directly map to > -webkit-appearance values (no need to change) For clarity, 1. really affects all existing -moz-appearance values that are not explicitly mentioned in 2. or 3. Once we alias -moz-appearance to -webkit-appearance then we will accept '-webkit-appearance: number-input' for example, and it will render as a number input. Other than that, and comment 32, your summary looks OK.

```css .btn { font-family: Helvetica, Arial, sans-serif; font-weight: bold; position: relative; display: inline-block; -webkit-box-sizing: border-box; -moz-box-sizing: border-box; box-sizing: border-box; cursor: pointer; -webkit-user-select: none; -moz-user-select: none; -ms-user-select: none; user-select: none; vertical-align: middle; -webkit-appearance: none; } select.is-tab-dropdown-more { position: absolute; right: -1px; width: 42px; height: 42px; background-image: url("/images/chevron_right.png"); background-repeat: no-repeat; background-position: 50%; background-color: #fff; text-indent: -9999px; } ```

Talked to Jet earlier today, and this really is a critical webcompat issue that we need to start implementing.

Thanks for taking this one, Jonathan!

Removing various webcompat.com reports that have been fixed by the site authors since being reported.

Putting back https://webcompat.com/issues/7612 which I removed by mistake, and removing three other issues that have also been fixed by the site authors.

18 of the webcompat issues that still exist are fixed by flipping the pref layout.css.webkit-appearance.enabled set to true: https://webcompat.com/issues/7007 https://webcompat.com/issues/7612 https://webcompat.com/issues/7760 https://webcompat.com/issues/9169 https://webcompat.com/issues/9896 https://webcompat.com/issues/9899 https://webcompat.com/issues/9973 https://webcompat.com/issues/12315 https://webcompat.com/issues/12821 https://webcompat.com/issues/12964 https://webcompat.com/issues/13038 https://webcompat.com/issues/13195 https://webcompat.com/issues/13895 https://webcompat.com/issues/15584 https://webcompat.com/issues/16344 https://webcompat.com/issues/17089 https://webcompat.com/issues/17090 https://webcompat.com/issues/17157

The only webcompat issue that's not fixed by enabling the pref is: https://webcompat.com/issues/7309 where the <select>s continue to get both themed and unthemed dropdown arrows. Google is serving different CSS inline in that page to Firefox vs. Chrome. For Firefox: appearance:button;appearance:button For Chrome: -webkit-appearance:button;appearance:button Firefox does not recognize 'appearance:button', so the <select> gets the default -moz-appearance value of 'menulist', but it also gets the 'background' image ( https://ssl.gstatic.com/ui/v1/disclosure/grey-disclosure-arrow-up-down.png ) that displays the other arrows. Chrome treats '-webkit-appearance:button' as computing to the value 'none' since the properties 'border', 'border-radius' and 'background-position' are set, so it only gets the arrows from the background image. (If -webkit-appearance wasn't set, the setting of those other properties would change the computed value from 'menulist' to 'menulist-button' for the record.) If Google was to serve '-moz-appearance:button' to Firefox then the <select>s would display correctly, although the computed value would be 'button' unlike for Chrome (since we don't disable theming when the properties 'border', 'border-radius' and 'background-position' are set). Serving '-moz-appearance:none' would also work and would also result in the same computed value.

Turns out issue 8034 is not fixed, it's just been hidden by the native Android theming implemented in bug 1352238 (thanks, Karl, for noticing!). However, flipping the pref on fixes the site.

I created this testcase to make it easier to compare the behavior of specific -webkit-appearance values across browsers and platforms. (The huge table isn't very conducive to that.)

Bug 1480073 turned on the -webkit-appearance alias for 63 (now in beta) behind EARLY_BETA_OR_EARLIER. Early beta finishes today, the next beta being beta 10 which will ship in 3 days (Friday). The only bug that I'm aware of that has been reported in beta 63 so far is bug 1492043, which seems like a WONTFIX. Given the lack of any other issues being reported let's go ahead with letting this ride to release in 63 as planed (baring any other issues turning up of course).

Comment on attachment 9011755 [details] Bug 1368555. Let -webkit-appearance ride the trains in v63. r?emilio Approval Request Comment [Feature/Bug causing the regression]: no regression, just keeping pref on for later-beta [User impact if declined]: lots of webcompat.com bugs [Is this code covered by automated tests?]: yes [Has the fix been verified in Nightly?]: yes, and early beta [Needs manual test from QE? If yes, steps to reproduce]: no [List of other uplifts needed for the feature/fix]: none [Is the change risky?]: seems low [Why is the change risky/not risky?]: been through nightly and early beta. have done what we can to reduce risk via an investigation into how -webkit-appearance is used. [String changes made/needed]: none

Comment on attachment 9011755 [details] Bug 1368555. Let -webkit-appearance ride the trains in v63. r?emilio Emilio Cobos Álvarez (:emilio) has approved the revision.

Comment on attachment 9011755 [details] Bug 1368555. Let -webkit-appearance ride the trains in v63. r?emilio Activated on nightly and beta since early August with only a minor issue reported (bug 1492043), on the other hand this fixes webcompat issues (comment #39) we have with many websites using the webkit-appearance property, among which high visibility sites. Uplift approved for 63 beta 10, thanks.

Pushed by jwatt@jwatt.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/fcd1fdbbad0d Let -webkit-appearance ride the trains in v63. r=emilio

The link to the landing on beta seems to be taking its time to show up here. In case that doesn't happen, here's the link: https://hg.mozilla.org/releases/mozilla-beta/rev/871364095b27

Pushes to release branches don't get marked automatically.

This is so cool. Thanks everybody.

Note to docs team: I've added a note about this to the Fx64 rel notes: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/64#CSS The rest of the docs work still needs doing (BCD, making sure we list all the available values, etc.).