New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 618472 link

Starred by 6 users

Issue metadata

Status: Fixed
Closed: Jul 30
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Feature

Blocked on:
issue 618518

issue 76362

Sign in to add a comment

Add WebView quirk setting for 8-digit colors

Project Member Reported by, Jun 8 2016

Issue description

In M52, Blink added support for #RRGGBBAA color format.  Unfortunately, 8-bit color is supported in Android with a AARRGGBB pattern, which leads to a common mistake within Android WebView app CSS to have such pattern, which was no-op before, but in newer versions of Chrome change instead makes blocks of content entirely transparent.

Android has a standard mechanism for introducing breaking API changes, known as targetSdkVersion.  Apps specify a targetSdkVersion in their manifest which states the highest Android version they have tested against.  It's safe to break apps starting at a particular version because that gives developers have an opportunity to make the necessary fixes, and endusers never see any breakage.

A representative example of how to do this is at  ( ), which was a similar CSS parsing change.  Because we have already noticed two WebView apps being affected (indicating it's a common mistake), and the symptoms are severe, in my opinion that approach is also called for here.  I've discussed this with sgurun@ and we agree this change should not be shipped to stable channel without a targetSdkVersion quirk, so marking this ReleaseBlock-Stable.

See also: 
Intent to ship discussion:!topic/blink-dev/Y6Q69fwcexo
Inbox app bug: http://b/28977540
Gmail app bug: http://b/29104000
Bug/CL for this CSS feature:  ,
Blockedon: 76362

Comment 2 by, Jun 8 2016

which sdk version does apps have to target, N or O?
this is not known since we cannot talk about android release dates here.
O is the safe version.
Blockedon: -76362 618518
Blocking: 76362
Labels: -M-52 -ReleaseBlock-Stable
I'll disable the feature in  issue 618518 , so this is no longer blocking.

Comment 6 by, Jun 16 2016

Would it make sense to enable just 4-digit colors?
Also, does this affect RGBA() format at all (e.g rgba(255, 255, 255, 1.0)?

Comment 7 by, Jun 20 2016

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.
Labels: -Type-Bug Type-Feature

Comment 9 by, Nov 14 2016

Owner: ----
Status: Available (was: Assigned)
Unassigning since I'm not currently working on this
Alright, should this be put on someone's TODO list?
Probably. Hey Rick - Perhaps this should go on one of the WebView people's queues?
Here's the main place where we configure web settings quirks based on target SDK version. Either someone can write a patch that plumbs this down to wherever it needs to go for this feature (and then we'll take care of making sure it gets documented in the release notes), or you can tell us where it needs to go and we can try to get to it.

The one thing that's tricky is that it needs to test against the *next* android release, whose SDK level is not yet set. I think we're currently planning to add a utility function for this to make it easier; I'll ping people and report back.
Status: Assigned (was: Available)
torne: This is controlled today via the CSSHexAlphaColorEnabled RuntimeEnabledFeature.  So the quirk should probably boil down to calling RuntimeEnabledFeatures::setCSSHexAlphaColorEnabled(false) when targetting an older SDK (but never explicitly setting it to true - leave that to blink to decide).

There's other places in content where we have Android-specific settings for RuntimeEnabledFeatures, eg:

But I don't see any existing plumbing from the above WebViewChromium into RuntimeEnabledFeatures.

So either we should:

1) Add some new plumbing from WebViewChromium down to WebRuntimeFeatures (plus the tiny bit of missing plumbing from WebRuntimeFeatures to RuntimeEnabledFeatures).  I think there'd be some Java work to this, so would probably be best for you guys to drive.


2) Add a new WebSetting (like the other quirks) that can disable support for this feature (independent of the RuntimeEnabledFeature - which we'd remove after shipping).  That would mostly be blink work, so should probably go to meade@'s style team.

I don't have a strong opinion of which is best.  Perhaps the latter is most consistent with what we're doing already (though I haven't looked exhaustively)  WDYT?  aelias?
I somewhat prefer approach 1) I think.  That will make for simpler code in the short term, and there is no particular reason to prefer WebSettings plumbing for targetSdkVersion quirks.  They fit the WebRuntimeFeatures "gradual release" idea fairly well and it may well become the new pattern to use indefinitely-maintained WebRuntimeFeatures for new targetSdkVersion quirks in the future.
Components: -Blink>CSS
Looks like WebView team is next to take action here, removing Blink>CSS.

looks like we missed the window for O :/

Comment 17 by, Jul 25 2017

Status: Started (was: Assigned)
Project Member

Comment 18 by, Jul 27 2017

The following revision refers to this bug:

commit f311a84728272e30979432e8474089b3db3c67df
Author: Noel Gordon <>
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 quirk. Also add

  setCSSHexAlphaColorEnabled(boolean enabled)

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

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

Covered by existing tests: see 


Bug:  76362 ,  618472 
Change-Id: Ibe52f5fdef77ae331be1eb95bfb9751eb197fc23
Reviewed-by: Mike West <>
Reviewed-by: Jochen Eisinger <>
Reviewed-by: Richard Coles <>
Reviewed-by: Bo Liu <>
Reviewed-by: Rick Byers <>
Reviewed-by: Alan Cutter <>
Reviewed-by: Sam McNally <>
Commit-Queue: Noel Gordon <>
Cr-Commit-Position: refs/heads/master@{#489808}

Comment 19 by, Sep 22 2017

Labels: M-62
M-62 is Beta channel now.  Quirk active for Android WebView, and I was about to mark fixed but...

Android-ilian's, who's gonna unquirk it some day :)  IIRC torne@ offered to when reviewing #18,  so do you want to take this bug as a reminder?

Comment 20 by, Sep 22 2017

Status: Assigned (was: Started)
Sure, I'll take it. Sorry we missed this for O; we'll get this sorted for the next release (we've had various discussions about how to deal with API levels better now).

Comment 21 by, Sep 22 2017

Sounds good, we'll get there, and thanks for your help with this.
Project Member

Comment 23 by, Dec 4 2017

The following revision refers to this bug:

commit e3526f77d76ab1277059880b3cc472ea25d64fe7
Author: Tobias Sargeant <>
Date: Mon Dec 04 16:26:02 2017

Enable CSS hex alpha and scrollTopLeftInterop based on P targetting

Bug:  618472 , 790008 
Change-Id: I663d380d14c927890a0863f4cb3158c2db1be408
Reviewed-by: Richard Coles <>
Commit-Queue: Tobias Sargeant <>
Cr-Commit-Position: refs/heads/master@{#521360}

So CSS hex alpha in WebView is now working from Android P onwards?  Can we close here?
Status: Fixed (was: Assigned)
Yup, sorry, Toby probably didn't notice this as he's not CCed on the bug. Any app that *targets* P or later in its manifest can use 8-digit CSS colors, even if it's running on an earlier OS version.

Sign in to add a comment