Bug 26030 – [Chromium] Chromium Linux ignores background color on <select>.

• Component: Layout and Rendering
• Status: RESOLVED FIXED

[Adam Langley]

Chromium Linux ignores background color on <select>. We always just draw the default gray gradient.

[Adam Langley]

Created attachment 30682 [details]
patch

[Eric Seidel (no email)]

Comment on attachment 30682 [details]
patch

Style issues.  no { } on single line ifs.

Don't we have a more efficient way to set this?

paint.setARGB(o->style()->backgroundColor().alpha(), o->style()->backgroundColor().red(), o->style()->backgroundColor().green(), o->style()->backgroundColor().blue());

There should be a way to pass a Color object to a SkPaint, I'm sure we have such a function somewhere.  color has a .rgb() accessor which probably returns a skpaint compatible int.

[Adam Langley]

Created attachment 30881 [details]
patch

Changes:

1) Color::rgb does indeed return a value which is
   compatible. However, it seems be a bit of a leap that the
   internal format of both Color and SkColor is register
   ARGB. Other platforms define specific constructors in
   Color. However, both RGBA32 and SkColor unwrap to an
   unsigned int, so we can't do that here.

   I've used .rgb() because it works and it's cleaner. I
   guess layout tests will catch if either side ever
   changes.

2) html4.css was specifiying a default background-color for
   buttons which meant that we could never tell if the page
   was setting one (which we should observe) or not (in
   which case we should draw our default button). So I added
   a CSS snippet to override this.

[Eric Seidel (no email)]

I'm pretty sure I added a COMPILE_ASSERT in ColorSkia.cpp that ensures that the internal formats are identical.  We could/should add an SkColor cast operator to Color as necessary though!

[Eric Seidel (no email)]

Comment on attachment 30881 [details]
patch

Still has the { } style issues.

The .css file should be a real .css file on disk and go through the normal processing scripts, no?


I think I would have written this:
+        if (!o->style()->hasBackground()) {
+            paint.setARGB(0xff, 0xe9, 0xe9, 0xe9);
+        } else {
+            paint.setColor(o->style()->backgroundColor().rgb());
+        }

As something like:

static Color defaultButtonGrey(0xff, 0xe9, 0xe9, 0xe9);
Color buttonBackground = !o->style()->hasBackground() ? o->style()->backgroundColor() : defaultButtonGrey;
paint.setColor(buttonBackground.rgb());

But this makes me wonder if CSS buttons (which do not go through the button theme calls) will look correct w/o a background?

[Adam Langley]

Created attachment 30920 [details]
patch

Next attempt:

This time we remove all the magic colour values from the paintButtonLike
function, except for a fallback colour. For painting <select>s and buttons, we
generate the family of colours needed by converting to HSL and changing the
luminance.

With this in hand, we set the CSS ButtonFace colour and the <select>
background-color and everything works out exactly the way is used to, except
that <select>'s with background colours are now handled correctly.

With this code, we could also handling drawing buttons with background-colors,
but that's something for another patch.

[Eric Seidel (no email)]

Comment on attachment 30920 [details]
patch

I would have given this color a name:
 129         return 0xffdddddd;

static Color someNiceNameForTheColor(0xffdddddd);
return someNiceNameForTheColor;

Braces get their own line:
 264 static float brightenColorCap(float in) {


Single line ifs don't get braces:
292     if (max == min) {
 293         hue = 0.f;
 294     } else if (max == r) {

Color functions belong on Color.h or somewhere in Skia...
 282 static SkColor brightenColor(SkColor base, float brightenAmount)

256341 static void paintButtonLike(RenderTheme* theme, RenderObject* o, const RenderObject::PaintInfo& i, const IntRect& rect) {
 need { on its own line too.

WK of course uses CamelCase:
 334     int final_r = 255.f * brightenColorDecode(p, q, tr);

Looks nice though! :)

r- for color stuff needing to move somewhere else.

[Adam Langley]

Created attachment 31019 [details]
patch

Moved the RGB->HSL conversion to Color and used the existing HSL->RGB conversion therein.

[Adam Langley]

Created attachment 31020 [details]
patch

[Eric Seidel (no email)]

Comment on attachment 31020 [details]
patch

Looks fine.  Please add a ChangeLog when landing.

Comment on attachment 31020 [details]
patch

Why the round-trip through HSL? Can't you just make a version of Color::light() that takes a parameter?

Comment on attachment 31020 [details]
patch

See <http://trac.webkit.org/changeset/21798>.

Never mind, you want HSL, not HSV!

[Adam Langley]

I could change Color::light, but the scaling of RGB components didn't work for me when I was playing around with different schemes. The colours I ended up with just didn't look quite right. I think HSL is the right way to do what I want here.

Comment on attachment 31020 [details]
patch

> +    while (hue >= 360.0)
> +        hue -= 360.0;
> +
> +    // makeRGBAFromHSLA assumes that hue is in [0...1).
> +    hue /= 360.0;

What is the purpose of the while loop?

> +    lightness = 0.5f * (max + min);

The "f" seems unhelpful at best.

> +    else if (lightness <= 0.5f)

Ditto.

[Adam Langley]

> What is the purpose of the while loop?

The spec said "mod 360", which is most accurately turned into a while loop.

Considering the case where max == r (which looks most likely to overflow 720 since it has the largest constant).

We have
hue = (60.0 * ((g - b) / (max - min))) + 360.0

so (g - b) / (max - min) must be < 6 in order not to overflow.

We know that max > g and max > b (since max == r) and that min == g or min == b.

Consider g >= b, thus b == min and thus g - b < max - min so the whole fraction is <= 1.
The alternative case leads, via similar reasoning to the fraction being >= -1.

So, we can change the while to an if. I'll do that.

The f's were a left over from when I wrote it with floats. I'll remove them, thanks.

[Brent Fulgham]

Landed in http://trac.webkit.org/changeset/44503.