New issue
Advanced search Search tips

Issue 810162 link

Starred by 1 user

Issue metadata

Status: Fixed
Closed: Jul 12
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: ----
Type: ----

Sign in to add a comment

[WPT] -webkit-appearance test in external/wpt/compat failing on Mac

Project Member Reported by, Feb 7 2018

Issue description

WPT import introduced new failures in external/wpt/compat:

List of new failures:
[ Mac-mac10.12 ] external/wpt/compat/webkit-appearance.tentative.html new failing tests:

This import contains upstream changes from 63e67be18169690b680ff6f87dbc7f02e6c8b55a to 141951354c4dc58a5dd7b6394c1b7e15dc8e3e30:
Merge pull request #9315 from stephenmcgruer/webkitAppearance:
[css-layout-api][css-paint-api] Generalize paintWorklet test runner to work with layoutWorklet.:
Update list of properties whitelisted for first-letter:
Add compat test for -webkit-appearance: [affecting this directory]


Comment 1 by, Feb 12 2018

Test added in

smcgruer@, I take it this failure on Mac was not known/anticipated? Can you take a look?
Status: Assigned (was: Untriaged)
It looks like this is caused by, which falls back to menulist-button for menulist on OSX only.

I'm not sure what we could do about this, other than fixing webkit-appearance on OSX?

Assigning to tkent, who originally authored the CL that does the fallback.

Comment 3 by, Feb 13 2018

Owner: ----
Status: Available (was: Assigned)
Both of WebKit and Blink have many kind of such fallback behavior, and it's observable with getComputedStyle().  So,

- The test doesn't reflect the reality
- Should Webkit and Blink stop exposing the fallback behavior via getComputerStyle() and adjust the appearance value internally?

Comment 4 by, Feb 13 2018

Summary: [WPT] -webkit-appearance test in external/wpt/compat failing on Mac (was: [WPT] New failures introduced in external/wpt/compat by import

Comment 5 by, Feb 13 2018

Components: Blink>CSS
Status: Assigned (was: Available)
Back to smcgruer@ with the "The test doesn't reflect the reality" challenge :)

tkent@, are the adjustments made here just affecting the visuals, or do they also change something else about the controls? (I don't know what the difference between -webkit-appearance:menulist and -webkit-appearnce:menulist-button is intended to be.)

Is Blink>CSS the right component for this?

Comment 6 by, Feb 14 2018

> tkent@, are the adjustments made here just affecting the visuals, or do they also change something else about the controls?

The purpose of the adjustments is to make web authors able to control more CSS properties on form controls, and they affect only element's metrics and painting result.

  <input type=search style="line-height:3em;"> doesn't have 3em line-height, but <input type=search style="line-height:3em; background: lime"> triggers the adjustment, makes computed -webkit-appearance "none", and makes line-height workable.

I am not a -webkit-appearance expert, or even a -webkit-appearance beginner. I am simply trying to ease the path forward for an existing web-compat issue; the existence (and common use) of -webkit-appearance, and the efforts of other browser vendors to also implement it[0].

In order for this feature to work across the web, it will one day have to be spec'd (most likely in I expect that on that day, the fact that -webkit-appearance: menulist (or any value) works differently on one OS than another in Chrome will be considered a Chrome bug. But I could be wrong!

I do not have steps forward for this bug. Possibly the best 'right now' behavior is to remove menulist from the WPT test with a comment referencing this bug, or perhaps we should just leave the test as failing on OSX. Or perhaps someone with more understanding can suggest a more currently interoperable WPT?

[0] Safari/Edge already support a subset of -webkit-appearance. Firefox plans to add full support:

Comment 8 by, Feb 15 2018

I recommend to remove the test.  It's too early to add tests.  We need an agreement on getComputedStyle() behavior.

Project Member

Comment 9 by, Feb 26 2018

The following revision refers to this bug:

commit 73c0ec5abceb2d983cbdbf5f3e95e3d1371822df
Author: Kent Tamura <>
Date: Mon Feb 26 15:50:35 2018

Count getComputedStyle() for -webkit-appearance

Now getComputedStyle() for -webkit-appearance returns adjusted values.
See [1].  We'd like to know whether we can remove this behavior or not.


Bug:  810162 
Change-Id: Icc17d681d7105d8a77ff07e18b7f270bd6918f01
Reviewed-by: Takayoshi Kochi <>
Reviewed-by: Daniel Cheng <>
Commit-Queue: Kent Tamura <>
Cr-Commit-Position: refs/heads/master@{#539142}

Project Member

Comment 10 by, Jul 12

The following revision refers to this bug:

commit af6945a93a039f0717fbc6037dd66a1db081fa65
Author: Stephen McGruer <>
Date: Thu Jul 12 13:22:01 2018

Remove webkit-appearance.tentative.html WPT test

This test is not a good indicator of -webkit-appearance support; it only
checks whether computed-value == applied-value for -webkit-appearance
values specified on a vanilla <div>. In reality most values of
-webkit-appearance are not of interest to other UAs (see, and the behavior is
different on different elements (e.g. <input>).

Since this has caused issues across different platforms on Chrome (see
bug), remove it.

Bug:  810162 
Change-Id: I9d469cb624569f453978f3c56cc180eb07435b5b
Reviewed-by: Kent Tamura <>
Commit-Queue: Stephen McGruer <>
Cr-Commit-Position: refs/heads/master@{#574546}

Status: Fixed (was: Assigned)

Sign in to add a comment