New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 16 users
Status: Fixed
Owner:
Closed: Sep 22
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Blocked on:
issue 618472
issue 611687
issue 618518



Sign in to add a comment
Feature request to add #RRGGBBAA and #RGBA as options for color hex values in CSS
Reported by paul.ne...@gmail.com, Mar 16 2011 Back to list
Currently the only way to specify a color with an alpha value is to use the rgba() syntax, such as:

.my-color {
    color: rgba(255, 255, 255, 0.5); /* half white */
}

This can become very unwieldy to write. A more succinct syntax could extend the current format of #rgb or #rrggbb to include #rgba or #rrggbbaa like so:

.my-color {
    color: #ffffff80; /* half white */
}

The browser could easily detect the difference between a 3 or 4 character hex value, or a 6 or 8 character hex value, and implement the alpha channel as appropriate.
 
Status: WontFix
This suggestion needs to go to the W3C; individual browsers don't decide CSS syntax. If the W3C approves it as part of the CSS spec, then Chrome will implement it.
Thanks. It's being discussed for CSS4 apparently: http://lists.w3.org/Archives/Public/www-style/2010Mar/0400.html
Comment 3 Deleted
Comment 4 Deleted
Cc: tabatkins@chromium.org
Status: Available
Spec in CSS Color Module Level 4
https://drafts.csswg.org/css-color/#hex-notation

Webkit patch:
http://trac.webkit.org/changeset/192023

Comment 7 by noel@chromium.org, May 2 2016
Cc: tabatkins@google.com
Discussion in #6 about the legacy color parsing rules for HTML attributes, code is in HTMLElement.cpp

// Color parsing that matches HTML's "rules for parsing a legacy color value" void HTMLElement::addHTMLColorToStyle(...)

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/html/HTMLElement.cpp&q=HTMLElement.cpp%20addHTMLColorToStyle&sq=package:chromium&type=cs&l=918

Code first tries parsedColor.setFromString (aka the CSS parser).  If that fails, codes falls back to the crazy parseColorStringWithCrazyLegacyRules().

If the CCS parser is updated to support the new #RRGGBBAA #RGBA syntax [1], some HTMLElement.idl legacy attribute color parses might change.  tab@ Is this a real concern?

[1] https://codereview.chromium.org/1936913002
Comment 8 by noel@chromium.org, May 2 2016
Labels: -Restrict-AddIssueComment-Commit OS-All
Comment 9 by noel@chromium.org, May 3 2016
Looking at the legacy parse code in HTMLElement::addHTMLColorToStyle, maybe we need only restrict it to use the CSS parser only for 3/6-digit hex colors.

That code is covered by fast/dom/attribute-legacy-colors.html, and adding such a restriction [1] produces these results for that test:

allow-css-color-parse: true [red] parsed #ff0000
allow-css-color-parse: true [red] parsed #ff0000
allow-css-color-parse: true [#f00] parsed #ff0000
allow-css-color-parse: true [#f00] parsed #ff0000
allow-css-color-parse: true [#ff0000] parsed #ff0000
allow-css-color-parse: true [#ff0000] parsed #ff0000
allow-css-color-parse: true [#fzz] parsed #0f0000
allow-css-color-parse: true [#ffzzzz] parsed #ff0000
allow-css-color-parse: true [f00] parsed #0f0000
allow-css-color-parse: true [ff0000] parsed #ff0000
allow-css-color-parse: false [#00000000] parsed #000000
allow-css-color-parse: true [foo] parsed #0f0000
allow-css-color-parse: true [cheese] parsed #c0ee0e
allow-css-color-parse: true [ff??ff] parsed #ff00ff
allow-css-color-parse: true [f??f] parsed #f00f00
allow-css-color-parse: true [rgb(255, 0, 0)] parsed #005500
allow-css-color-parse: true [rgba(255,255,255,50%)] parsed #005055
allow-css-color-parse: true [hsl(180,100%,50%)] parsed #000150
allow-css-color-parse: true [hsla(180,100%,50%,50%)] parsed #001005
allow-css-color-parse: true [currentColor] parsed #c0e000
allow-css-color-parse: true [550000001155000000115500000011] parsed #111111
allow-css-color-parse: true [550000000155000000015500000001] parsed #010101
allow-css-color-parse: true [550000000055000000005500000000] parsed #000000
allow-css-color-parse: true [550020001155000000115500000011] parsed #200000
allow-css-color-parse: true [55??20??1155????00115500??0011] parsed #200000
allow-css-color-parse: false [#] parsed #000000
allow-css-color-parse: false [#5] parsed #050000
allow-css-color-parse: false [#55] parsed #050500
allow-css-color-parse: true [#555] parsed #555555
allow-css-color-parse: false [#5555] parsed #555500
allow-css-color-parse: false [#55555] parsed #555550
allow-css-color-parse: true [#555555] parsed #555555
allow-css-color-parse: false [#5555555] parsed #555550
allow-css-color-parse: false [#55555555] parsed #555555
allow-css-color-parse: true [5] parsed #050000
allow-css-color-parse: true [55] parsed #050500
allow-css-color-parse: true [555] parsed #050505
allow-css-color-parse: true [5555] parsed #555500
allow-css-color-parse: true [55555] parsed #555550
allow-css-color-parse: true [555555] parsed #555555
allow-css-color-parse: true [5555555] parsed #555550
allow-css-color-parse: true [55555555] parsed #555555
allow-css-color-parse: true [ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff000000] parsed #ffffff
allow-css-color-parse: true [????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????ffffff] parsed #000000
allow-css-color-parse: false [] parsed #000000
allow-css-color-parse: true 

aka, no change in legacy behavior.

[1] https://codereview.chromium.org/1936913002/#ps20001
Comment 10 by noel@chromium.org, May 5 2016
Cc: d...@apple.com
Owner: noel@chromium.org
#7 > If the CCS parser is updated to support the new #RRGGBBAA #RGBA syntax [1], some HTMLElement.idl legacy attribute color parses might change.  tab@ Is this a real concern?

¯\(ツ)/¯ I suppose a moot question given #9, and fast/dom/attribute-legacy-colors.html not changing behavior with my patch.

+dino: Dean, sorry to ping here, but I'm adding your change [1] to Blink and noticed fast/dom/attribute-legacy-colors.html changed behavior with your patch.  Wasn't sure if that was intentional, or just an oversight, w.r.t. preserving legacy color parsing behavior?

Hixie suggested we preserve it ( see https://bugzilla.mozilla.org/show_bug.cgi?id=567283#c9 ) and I will probably go that way, but won't have exact compat with Safari in a legacy color parse :(

Thoughts?

[1] http://trac.webkit.org/changeset/192023
I wrote this patch for WebKit like 5 years ago! I hadn't written the spec yet, tho, so Hyatt rejected it. :(

Yes, you do need to protect legacy HTML attributes from receiving this update - when I wrote the WebKit patch, I found a handful of sites that were using <font color="#00000000"> and expecting black text (not transparent).  Cleanest way is to just simplify the check in addHTMLColorToStyle() to first just check for a named color (via setNamedColor()) and then if it fails, fall directly into the crazy parsing.  Crazy parsing handles 3/6 hex-digit values no problem, it's just a bit slower than the "normal" hex parsing.

If Dino didn't preserve legacy HTML behavior with his patch, that's a WebKit bug. :(
Comment 12 by d...@apple.com, May 5 2016
Hello.

Changing legacy HTML parsing was an oversight. I didn't look at Tab's original patch. If he did maintained the legacy behaviour there, I probably should have looked at it :)

If you all think it is worth maintaining, I'll fix it in WebKit. I'm not really bothered either way.

I have got some reports of CSS breakage, where people had buggy 4 or 8 character colors in their stylesheet which were previously being ignored.
Comment 13 by d...@apple.com, May 6 2016
> Cleanest way is to just simplify the check in addHTMLColorToStyle() to first just check for a named color (via setNamedColor()) and then if it fails, fall directly into the crazy parsing.  Crazy parsing handles 3/6 hex-digit values no problem

Alas, it doesn't.

    if (digitBuffer.size() < 6)
        return makeRGB(toASCIIHexValue(digitBuffer[0]), toASCIIHexValue(digitBuffer[1]), toASCIIHexValue(digitBuffer[2]));

A string of "F00" is converted to makeRGB(15, 0, 0).

The crazy color parsing really is crazy. "#f00" is different from "f00". As soon as you understand why that is, you notice "#fzz" acts more like "f00" than "#f00".

Maybe the easiest solution here is to special case the "#00000000" attribute value?
Comment 14 by d...@apple.com, May 6 2016
Or, try to use Color(colorString) if colorString starts with a '#' and is followed by 3 or 6 characters. If that fails, then go to crazy town.
Sigh, yeah, still need an explicit check.  So yeah:

1. If it's 4/7 characters and the first is a '#', try to parse it as CSS.
2. Otherwise, or if the previous step fails, try to parse it as a named color.
3. Otherwise, crazy town.
Comment 16 by d...@apple.com, May 6 2016
That's exactly what I was going to land in about 2 minutes.
Comment 17 by d...@apple.com, May 6 2016
s/was/am/

Comment 18 by noel@chromium.org, May 6 2016
Something like this https://codereview.chromium.org/1936913002/patch/20001/30016 Dean?  fast/dom/attribute-legacy-colors.html does not change behavior when I do that.
Comment 20 by noel@chromium.org, May 6 2016
"crazypants algorithm", love the description Dean, we should maybe rename that routine to parseColorStringWithCrazyPantsLegacyRules() one day :)

Seriously though, yeah, your change looks good to me.  Let's go with that.
Comment 21 by d...@apple.com, May 6 2016
I landed this in https://trac.webkit.org/r200501

I hoped that "Crazypants" was less offensive to people with a mental illness. After all, crazy pants can be great! :)

I'm really at a loss to understand how this algorithm evolved over time. I guess it was slowly, first accepting strings without the hash, and so on.
Comment 22 by noel@chromium.org, May 6 2016
> I landed this in https://trac.webkit.org/r200501

Thanks Dean.  I wrote a patch derived from that, and added attribution to the ChangeLog, https://codereview.chromium.org/1936913002/#ps40001

> I hoped that "Crazypants" was less offensive to people with a mental illness. After all, crazy pants can be great! :)

Yeah, and shows consideration for the feelings of others here, well played.

> I'm really at a loss to understand how this algorithm evolved over time. I guess it was slowly, first accepting strings without the hash, and so on.

... the result has some patina.

Dean, Tab: thank you both for your help and input resolving this issue.  We have compat, and I can move on to shipping.  Thanks again.
Comment 24 by noel@chromium.org, May 6 2016
Status: Started
Comment 25 by noel@chromium.org, May 7 2016
Intent to Ship: Accept 8 (#RRGGBBAA) and 4 (#RGBA) value hex colors

Sent to blink-dev@
Comment 26 by noel@chromium.org, May 7 2016
Cc: timloh@chromium.org
Comment 27 by noel@chromium.org, May 9 2016
dbaron mentioned https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk (step 4).

and that the behavior of this "hashless color quirk" should also not change and so continue to support only 3 and 6 digit hex colors.

Test is fast/css/parsing-color-quirk.html and it does not test 4/8 hex digits, sadly.  So we need to add some 4/8 hex digit coverage to that test, and fix the parser color quirk code ...
Comment 28 by noel@chromium.org, May 12 2016
Re: #27 "the-hashless-color-quirk", yeah, I needed to change Blink's

 Source/core/css/parser/CSSPropertyParserHelpers.cpp

See patch-set #4 https://codereview.chromium.org/1936913002/#ps60001




Project Member Comment 29 by bugdroid1@chromium.org, May 13 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bd42b3e0e1e52b1cbfe630ac7a4c230779111682

commit bd42b3e0e1e52b1cbfe630ac7a4c230779111682
Author: noel <noel@chromium.org>
Date: Fri May 13 03:03:06 2016

[CSS] Accept 8 (#RRGGBBAA) and 4 (#RGBA) value hex colors

CSS Color Level 4 allows #RRGGBBAA and #RGBA colors. Update
Color.cpp parsing for the new syntax. Add a test, ditch the
canvas/philip invalid hex tests, update existing tests.

Refer to https://bugs.webkit.org/show_bug.cgi?id=150853 and
the patch by Dean Jackson to resolve which is included here
verbatim, with additional support for legacy HTML attribute
color parsing based on Dean's follow-up patch [1].

Obsolete legacy HTML attributes parse colors via the "rules
for parsing a legacy colour value" of the HTML micro syntax
(see http://bit.ly/1WF2Yre). Limit legacy parsing to accept
only 3/6-digit hex color for compat, add a comment (covered
by fast/dom/attribute-legacy-colors.html).

Fix quirks mode color parse, per http://bit.ly/1VPZFic, and
update fast/css/parsing-color-quirk.html with 4/8 digit hex
color test cases for the-hashless-hex-color-quirk.

Finally, in Blink's fastParseColorInternal() CSS fast path,
only allow hashless 3/6-digit hex color in quirks mode, add
test cases to fast/css/parsing-color-quirk.html.

Spec: https://drafts.csswg.org/css-color/#hex-notation

Change in behavior: add fast/css/hex-colors.html

[1] http://trac.webkit.org/changeset/200501

BUG= 76362 

Review-Url: https://codereview.chromium.org/1936913002
Cr-Commit-Position: refs/heads/master@{#393438}

[delete] https://crrev.com/145bd98e6e7e84a60fbc489d79d08b51c51bdf23/third_party/WebKit/LayoutTests/canvas/philip/tests/2d.fillStyle.parse.invalid.hex4-expected.txt
[delete] https://crrev.com/145bd98e6e7e84a60fbc489d79d08b51c51bdf23/third_party/WebKit/LayoutTests/canvas/philip/tests/2d.fillStyle.parse.invalid.hex4.html
[delete] https://crrev.com/145bd98e6e7e84a60fbc489d79d08b51c51bdf23/third_party/WebKit/LayoutTests/canvas/philip/tests/2d.fillStyle.parse.invalid.hex8-expected.txt
[delete] https://crrev.com/145bd98e6e7e84a60fbc489d79d08b51c51bdf23/third_party/WebKit/LayoutTests/canvas/philip/tests/2d.fillStyle.parse.invalid.hex8.html
[modify] https://crrev.com/bd42b3e0e1e52b1cbfe630ac7a4c230779111682/third_party/WebKit/LayoutTests/css-parser/color3-expected.txt
[modify] https://crrev.com/bd42b3e0e1e52b1cbfe630ac7a4c230779111682/third_party/WebKit/LayoutTests/css-parser/resources/css-parsing-tests/color3.json
[add] https://crrev.com/bd42b3e0e1e52b1cbfe630ac7a4c230779111682/third_party/WebKit/LayoutTests/fast/css/hex-colors-expected.txt
[add] https://crrev.com/bd42b3e0e1e52b1cbfe630ac7a4c230779111682/third_party/WebKit/LayoutTests/fast/css/hex-colors.html
[modify] https://crrev.com/bd42b3e0e1e52b1cbfe630ac7a4c230779111682/third_party/WebKit/LayoutTests/fast/css/invalid-hex-color-expected.txt
[modify] https://crrev.com/bd42b3e0e1e52b1cbfe630ac7a4c230779111682/third_party/WebKit/LayoutTests/fast/css/invalid-hex-color.html
[modify] https://crrev.com/bd42b3e0e1e52b1cbfe630ac7a4c230779111682/third_party/WebKit/LayoutTests/fast/css/invalid-predefined-color-expected.txt
[modify] https://crrev.com/bd42b3e0e1e52b1cbfe630ac7a4c230779111682/third_party/WebKit/LayoutTests/fast/css/invalid-predefined-color.html
[modify] https://crrev.com/bd42b3e0e1e52b1cbfe630ac7a4c230779111682/third_party/WebKit/LayoutTests/fast/css/parsing-color-quirk.html
[modify] https://crrev.com/bd42b3e0e1e52b1cbfe630ac7a4c230779111682/third_party/WebKit/LayoutTests/fast/css/script-tests/invalid-predefined-color.js
[modify] https://crrev.com/bd42b3e0e1e52b1cbfe630ac7a4c230779111682/third_party/WebKit/LayoutTests/svg/dom/rgb-color-parser-expected.txt
[modify] https://crrev.com/bd42b3e0e1e52b1cbfe630ac7a4c230779111682/third_party/WebKit/LayoutTests/svg/dom/rgb-color-parser.html
[modify] https://crrev.com/bd42b3e0e1e52b1cbfe630ac7a4c230779111682/third_party/WebKit/Source/core/css/parser/CSSParserFastPaths.cpp
[modify] https://crrev.com/bd42b3e0e1e52b1cbfe630ac7a4c230779111682/third_party/WebKit/Source/core/css/parser/CSSPropertyParserHelpers.cpp
[modify] https://crrev.com/bd42b3e0e1e52b1cbfe630ac7a4c230779111682/third_party/WebKit/Source/core/html/HTMLElement.cpp
[modify] https://crrev.com/bd42b3e0e1e52b1cbfe630ac7a4c230779111682/third_party/WebKit/Source/platform/graphics/Color.cpp

Comment 30 by noel@chromium.org, May 17 2016
#12 Dino > I have got some reports of CSS breakage, where people had buggy 4 or 8 character colors in their stylesheet which were previously being ignored.

Yeah, one reported already for a quirks-mode document:  issue 612126 .

Spec-wise gents, is there a rule to follow here?  Quirks mode document and a #RGBA or #RRGGBBAA color.  Per spec, should we accept or deny them?
Comment 31 by noel@chromium.org, May 19 2016
Blockedon: 611687
Labels: M-52
There's no strict rule. We bow to compat as it proves itself necessary, but it's common for small changes like this to run into accidental values like this in small numbers of cases.

This shouldn't become a quirks-mode quirk unless it's shown to (a) be common enough to need fixing, and (b) disproportionately show up in quirks-mode documents as opposed to standards-mode.  In general, we're not adding new quirks except when browser archaeology shows some spec violation we didn't notice several browsers have been doing for a long time.

For this case, I suspect the compat impact will be small. We should wait and see.
Comment 33 by noel@chromium.org, May 23 2016
Sounds good to me.  I closed  issue 612126  yesterday similarly (no desire to add more spec quirks).  Let's wait and see.
Comment 34 by noel@chromium.org, May 26 2016
Status: Fixed
Chrome devtools support done:  issue 611687 .
Blocking: 618472
Blocking: -618472
Blockedon: 618472
Blockedon: 618518
Status: Assigned
Re-opening due to disable in  issue 618518 .
Project Member Comment 39 by bugdroid1@chromium.org, Jun 9 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b7bc5783027ae86ff6eb6912d0a6112cda6a8814

commit b7bc5783027ae86ff6eb6912d0a6112cda6a8814
Author: rbyers <rbyers@chromium.org>
Date: Thu Jun 09 04:57:08 2016

Disable 4 and 8 digit hex CSS colors

New compat concerns have been raised with 4 and 8 digit HEX color
values in CSS.  In particular, a targetSdk quirk needs to be added
for Android WebView to avoid breaking Android apps.

Demote this feature to "experimental" status until an owner can be found.

BUG= 618518 ,  76362 

Review-Url: https://codereview.chromium.org/2047413003
Cr-Commit-Position: refs/heads/master@{#398789}

[modify] https://crrev.com/b7bc5783027ae86ff6eb6912d0a6112cda6a8814/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.in
[modify] https://crrev.com/b7bc5783027ae86ff6eb6912d0a6112cda6a8814/third_party/WebKit/Source/platform/graphics/Color.cpp

Comment 40 by d...@apple.com, Jun 9 2016
This is a shame.

Why are Android apps using 4 or 8 digit hex colors in a way that is incompatible?
If you follow the issue through to the blink-dev thread at <https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/Y6Q69fwcexo/EhGUN_ySBgAJ>, the issue is that Android apps have supported alpha-hex for a while, but in ARGB format, so there's some accidental leakage into WebView-based apps where app authors try to use it in their CSS.  It was previously just invalid, but now is accidentally firing and messing up display.

In particular, this hit two of Google's apps. They're fixed already, but on the assumption that this will hit a reasonable percentage of other apps, we're going to deploy our targetSdk quirk to prevent breakage, then turn this back on globally.
Comment 42 by d...@apple.com, Jun 9 2016
Sounds good. I think we'll go ahead and ship with it then (although I still need to copy the last compat fix that Noel made)
Yeah, this shouldn't have any effect on y'all. Have fun with it, we'll catch up asap.
Project Member Comment 44 by sheriffbot@chromium.org, Jun 14 2016
Labels: -M-52 M-53 MovedFrom-52
Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Owner: meade@chromium.org
Talked with Eddy, she said this might make sense for style-dev to own while Noel is out.  Assigning to her for further routing / triage.
Project Member Comment 46 by bugdroid1@chromium.org, Jun 20 2016
Labels: merge-merged-2743
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1c24aa54c19c702703d68bc0bc62b7a5449d3755

commit 1c24aa54c19c702703d68bc0bc62b7a5449d3755
Author: Rick Byers <rbyers@chromium.org>
Date: Mon Jun 20 21:20:27 2016

Disable 4 and 8 digit hex CSS colors

New compat concerns have been raised with 4 and 8 digit HEX color
values in CSS.  In particular, a targetSdk quirk needs to be added
for Android WebView to avoid breaking Android apps.

Demote this feature to "experimental" status until an owner can be found.

BUG= 618518 ,  76362 

Review-Url: https://codereview.chromium.org/2047413003
Cr-Commit-Position: refs/heads/master@{#398789}
(cherry picked from commit b7bc5783027ae86ff6eb6912d0a6112cda6a8814)

Review URL: https://codereview.chromium.org/2086433003 .

Cr-Commit-Position: refs/branch-heads/2743@{#413}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/1c24aa54c19c702703d68bc0bc62b7a5449d3755/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.in
[modify] https://crrev.com/1c24aa54c19c702703d68bc0bc62b7a5449d3755/third_party/WebKit/Source/platform/graphics/Color.cpp

Labels: TE-Verified-M52 TE-Verified-52.0.2743.49
As per the test steps in   bug 618518  Tested the issue on windows 7, Linux Ubuntu 14.04 and Mac 10.11.5 using chrome version 52.0.2743.49 with URL  http://jsbin.com/moyobo.Able see the transparent box.Hence adding TE-Verified label.

Thanks,
618518.png
71.2 KB View Download
I updated the chromestatus.com entry. Please, keep it up to date.
Comment 49 by meade@chromium.org, Nov 14 2016
Components: Blink>CSS
Owner: ----
Status: Available
Reenabling this is blocked on https://bugs.chromium.org/p/chromium/issues/detail?id=618472
Labels: Hotlist-Interop
Cc: noel@chromium.org
Labels: Update-Quarterly
Labels: -M-53 M-62
Owner: noel@chromium.org
Status: Started
Project Member Comment 54 by bugdroid1@chromium.org, Jul 27
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f311a84728272e30979432e8474089b3db3c67df

commit f311a84728272e30979432e8474089b3db3c67df
Author: Noel Gordon <noel@chromium.org>
Date: Thu Jul 27 00:10:07 2017

[CSS4] Accept 8 (#RRGGBBAA) and 4 (#RGBA) value hex colors

Move this CSS feature from experimental back to stable under the
prior Blink intent-to-ship [1] ( bug 76362 ) and re-ship (M62).

Block this feature on the Android WebView however (due to chrome
bug 618472) using a AwSettings.java quirk. Also add

  setCSSHexAlphaColorEnabled(boolean enabled)

to AwSettings.java which WebViewChromium.java could call once the
TargetSdkVersion to use for this WebView quirk is known.

Add an AwSettingsTest.java test to test that support for this CSS
feature is off by default in the Android WebView.

Covered by existing tests: see  crbug.com/76362#c29 

[1] http://bit.ly/1q94VPR

Bug:  76362 , 618472
Change-Id: Ibe52f5fdef77ae331be1eb95bfb9751eb197fc23
Reviewed-on: https://chromium-review.googlesource.com/560926
Reviewed-by: Mike West <mkwst@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Richard Coles <torne@chromium.org>
Reviewed-by: Bo Liu <boliu@chromium.org>
Reviewed-by: Rick Byers <rbyers@chromium.org>
Reviewed-by: Alan Cutter <alancutter@chromium.org>
Reviewed-by: Sam McNally <sammc@chromium.org>
Commit-Queue: Noel Gordon <noel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#489808}
[modify] https://crrev.com/f311a84728272e30979432e8474089b3db3c67df/android_webview/browser/aw_settings.cc
[modify] https://crrev.com/f311a84728272e30979432e8474089b3db3c67df/android_webview/java/src/org/chromium/android_webview/AwSettings.java
[modify] https://crrev.com/f311a84728272e30979432e8474089b3db3c67df/android_webview/javatests/src/org/chromium/android_webview/test/AwSettingsTest.java
[modify] https://crrev.com/f311a84728272e30979432e8474089b3db3c67df/content/public/common/common_param_traits_macros.h
[modify] https://crrev.com/f311a84728272e30979432e8474089b3db3c67df/content/public/common/web_preferences.cc
[modify] https://crrev.com/f311a84728272e30979432e8474089b3db3c67df/content/public/common/web_preferences.h
[modify] https://crrev.com/f311a84728272e30979432e8474089b3db3c67df/content/renderer/render_view_impl.cc
[modify] https://crrev.com/f311a84728272e30979432e8474089b3db3c67df/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.json5
[modify] https://crrev.com/f311a84728272e30979432e8474089b3db3c67df/third_party/WebKit/Source/platform/exported/WebRuntimeFeatures.cpp
[modify] https://crrev.com/f311a84728272e30979432e8474089b3db3c67df/third_party/WebKit/public/platform/WebRuntimeFeatures.h

Project Member Comment 55 by bugdroid1@chromium.org, Jul 27
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5b57665fd1db6ae64c4809f2c66eba1538f7e21d

commit 5b57665fd1db6ae64c4809f2c66eba1538f7e21d
Author: Noel Gordon <noel@chromium.org>
Date: Thu Jul 27 00:35:22 2017

Devtools: Support 8 (#RRGGBBAA) and 4 (#RGBA) value hex colors

Recover the patch (reverted on  issue 621538 ) to add support for CSS
8 and 4 hex color [1]. Re-work that patch into devtools current and
update inspector layout tests.

[1] https://codereview.chromium.org/1986053004

Bug:  76362 ,  611687 
Change-Id: I8adbd9c67f5960481759ec097817196e874355ef
Reviewed-on: https://chromium-review.googlesource.com/567841
Commit-Queue: Noel Gordon <noel@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Joel Einbinder <einbinder@chromium.org>
Cr-Commit-Position: refs/heads/master@{#489813}
[modify] https://crrev.com/5b57665fd1db6ae64c4809f2c66eba1538f7e21d/third_party/WebKit/LayoutTests/inspector/components/color-expected.txt
[modify] https://crrev.com/5b57665fd1db6ae64c4809f2c66eba1538f7e21d/third_party/WebKit/LayoutTests/inspector/components/color.html
[modify] https://crrev.com/5b57665fd1db6ae64c4809f2c66eba1538f7e21d/third_party/WebKit/LayoutTests/inspector/elements/styles-3/spectrum-expected.txt
[modify] https://crrev.com/5b57665fd1db6ae64c4809f2c66eba1538f7e21d/third_party/WebKit/LayoutTests/inspector/elements/styles-3/spectrum.html
[modify] https://crrev.com/5b57665fd1db6ae64c4809f2c66eba1538f7e21d/third_party/WebKit/LayoutTests/inspector/elements/styles-4/styles-invalid-color-values-expected.txt
[modify] https://crrev.com/5b57665fd1db6ae64c4809f2c66eba1538f7e21d/third_party/WebKit/LayoutTests/inspector/elements/styles-4/styles-invalid-color-values.html
[modify] https://crrev.com/5b57665fd1db6ae64c4809f2c66eba1538f7e21d/third_party/WebKit/Source/devtools/front_end/color_picker/Spectrum.js
[modify] https://crrev.com/5b57665fd1db6ae64c4809f2c66eba1538f7e21d/third_party/WebKit/Source/devtools/front_end/common/Color.js
[modify] https://crrev.com/5b57665fd1db6ae64c4809f2c66eba1538f7e21d/third_party/WebKit/Source/devtools/front_end/inline_editor/ColorSwatch.js

*bug report*
Chrome 60 (from what I've read isn't even supporting this without the experimental flag) supports #RRGGBBAA hex colour notation when the last two values are as a percentage value not hex value, e.g #FF000099 will give red at 99% opacity while FF0000FF and FF000000 are the same (0% opacity) and values such as #FF000075 will give red at 75% opacity.
#56 -
Sounds weird, do the values in the committed tests look fine to you?
https://chromium.googlesource.com/chromium/src.git/+/bd42b3e0e1e52b1cbfe630ac7a4c230779111682%5E%21/#F6
+PASS #123x4567 was red:255 green: 0 blue: 0 -> Invalid Value
+PASS #00000012 was red:0 green: 0 blue: 0 alpha: 18 -> Pass
+PASS #0001 was red:0 green: 0 blue: 0 alpha: 17 -> Pass
+PASS #123x was red:255 green: 0 blue: 0 -> Invalid Value
Although they're displayed like so:
http://i.imgur.com/Jfgov8f.png
Ok actually managed to run the test quicker than I thought:
PASS #000 was red:0 green: 0 blue: 0
PASS #001 was red:0 green: 0 blue: 17
PASS #012 was red:0 green: 17 blue: 34
PASS #123 was red:17 green: 34 blue: 51
PASS #0001 was red:0 green: 0 blue: 0 alpha: 17
PASS #0012 was red:0 green: 0 blue: 17 alpha: 34
PASS #0123 was red:0 green: 17 blue: 34 alpha: 51
PASS #1234 was red:17 green: 34 blue: 51 alpha: 68
PASS #000000 was red:0 green: 0 blue: 0
PASS #000012 was red:0 green: 0 blue: 18
PASS #001234 was red:0 green: 18 blue: 52
PASS #123456 was red:18 green: 52 blue: 86
PASS #00000000 was red:0 green: 0 blue: 0 alpha: 0
PASS #00000012 was red:0 green: 0 blue: 0 alpha: 18
PASS #00001234 was red:0 green: 0 blue: 18 alpha: 52
PASS #00123456 was red:0 green: 18 blue: 52 alpha: 86
PASS #12345678 was red:18 green: 52 blue: 86 alpha: 120
PASS #12x3 was red:255 green: 0 blue: 0
PASS #123x was red:255 green: 0 blue: 0
PASS #123x4567 was red:255 green: 0 blue: 0
PASS #1234567r was red:255 green: 0 blue: 0
PASS #123456x6 was red:255 green: 0 blue: 0
#60 -
Looks like it passes for you, too.

#59 -
I believe the Developer Tools feature has only recently (days) gained support for the 8 hexadecimal character notation, so perhaps this is what you are missing?
Status: Fixed
M62 is now Beta, it's been 12 weeks on the channels Canary, Dev, ... and no issues so far.  Marking fixed.
Can confirm my issue has been fixed on the stable channel.
Thanks Brandon, maybe check M62 Beta Channel if you have time, and make sure it's fixed there too :)
Sign in to add a comment