Closed Bug 1368555 Opened 7 years ago Closed 6 years ago

[Meta] Implement -webkit-appearance


(Core :: CSS Parsing and Computation, enhancement, P2)




Tracking Status
firefox63 --- fixed
firefox64 --- fixed


(Reporter: MatsPalmgren_bugz, Assigned: jwatt)


(Depends on 3 open bugs, Blocks 1 open bug, )


(6 keywords, Whiteboard: [webcompat:p1] [geckoview:klar:p3])

User Story

Business driver: Mobile Webcompat (multiple site issues reported), needed to ship geckoview

Note: Likely compat fallout


(6 files)

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

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?
Keywords: dev-doc-needed
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.
Blocks: 1349835
I'll try to document all the cases I meet/met (new and old).

leroy-merlin - mobile site

relies on 

select {
	-webkit-appearance: initial;

to remove the widget, aka default to -webkit-appearance: none;
Flags: webcompat?
Whiteboard: [webcompat]
Only -webkit-appearance: none is provided.
This is the most common case.

#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.

for the site on mobile

.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.
-webkit-appearance: none and background image.

.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;
Blocks: 454625

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

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.
See also about -webkit-appearance: inherit.
Blocks: 1357655
In the current state of YouTube.
This is a case where `-webkit-appearance: none` will break things once implemented in Firefox.

putting it here as a reminder.
See Also: → 9899
input[type="checkbox"] {
	background-image: url("");
	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;
Blocks: 1405085
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?
Flags: needinfo?(mats)
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.

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

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.
Flags: needinfo?(miket)
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]:


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 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 @

-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.
Flags: needinfo?(miket)
(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
> 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:

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).
Flags: needinfo?(mats)
BTW, I think we can ignore the scrollbar* values listed in
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:

input[type="submit"],input[type="text"],input[type="password"] {
select {
 background:#fff url(images/dropdown.gif) no-repeat right center;
.reevoo-select {
I have investigated into the 51 -webkit-appearance values listed here
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?
Flags: needinfo?(mats)
Depends on: 1413373
Depends on: 1246836
(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.
Flags: needinfo?(mats)
(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

And one in WebKit

on macOS on Chrome Canary and Safari Tech Preview, they both seem to have no effect.
No longer depends on: 1413373
Right, it appears to be associated with the ::-webkit-progress-value
pseudo element:

We have a corresponding ::-moz-progress-bar pseudo(*) which has
'-moz-appearance: progresschunk':

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)

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
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
Flags: needinfo?(mats)
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?

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.
Flags: needinfo?(mats)

.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;
} {
	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;
Depends on: 1415789
Depends on: 1417751
Depends on: 1417753
Summary: Implement -webkit-appearance → [Meta] Implement -webkit-appearance
Depends on: 1428676
Depends on: 1429700
Flags: webcompat? → webcompat+
Whiteboard: [webcompat] → [webcompat:p1]
User Story: (updated)
User Story: (updated)
Blocks: 1170789
Whiteboard: [webcompat:p1] → [webcompat:p2]
Talked to Jet earlier today, and this really is a critical webcompat issue that we need to start implementing.
User Story: (updated)
Whiteboard: [webcompat:p2] → [webcompat:p1]
Priority: P3 → P2
Thanks for taking this one, Jonathan!
Assignee: nobody → jwatt
Depends on: 1429713
No longer depends on: 1429700
Whiteboard: [webcompat:p1] → [webcompat:p1] [geckoview:klar:p3]
Putting back which I removed by mistake, and removing three other issues that have also been fixed by the site authors.
The only webcompat issue that's not fixed by enabling the pref is:

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 ( ) 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.
Blocks: 1480073
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.)
See Also: → 1481581
See Also: → 1488711
See Also: → 1351745
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 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
Attachment #9011755 - Flags: approval-mozilla-beta?
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.
Attachment #9011755 - Flags: review+
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.
Attachment #9011755 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Pushed by
Let -webkit-appearance ride the trains in v63. r=emilio
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
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:
Pushes to release branches don't get marked automatically.
Target Milestone: mozilla63 → mozilla64
This is so cool. Thanks everybody.
Depends on: 1500423
Depends on: 1501483
Depends on: 1501499
Depends on: 1501506
Note to docs team:

I've added a note about this to the Fx64 rel notes:

The rest of the docs work still needs doing (BCD, making sure we list all the available values, etc.).
You need to log in before you can comment on or make changes to this bug.