[Chromium] select box dropdown list backgound colour error

• Component: Forms
• Status: RESOLVED DUPLICATE

[Bákonyi Zsolt]

The background of a select box is black f.e, and the text colour is yellow. When you click on the select box, the dropdown list background will be white but the text colour still yellow and the text will be unreadable.

[Bákonyi Zsolt]

Created attachment 110127 [details]
The bug itself

[Vineet Chaudhary (vineetc)]

Created attachment 110129 [details]
test_case

Attaching test
verified on chrome-linux.
If select element has "background-color:black" then is not inherited to option elements.
Mozilla works fine with this.
I am analyzing this issue more any comments are welcome.

[Vineet Chaudhary (vineetc)]

Old bugzilla reference : https://bugs.webkit.org/show_bug.cgi?id=9846

[Alexey Proskuryakov]

Yes, looks like a duplicate of bug 9846.

*** This bug has been marked as a duplicate of bug 9846 ***

[Alexey Proskuryakov]

Actually, we still need separate bugs for different platforms, so not tracking as duplicate.

[Vineet Chaudhary (vineetc)]

There is inconsistent chromium behavior for this test case as, this issue is not reproducible on chromium-windows.

After debugging through code below are few observations:

1) In RenderMenuList::itemBackgroundColor() this function there is if checks as (line 475):

    // If the item has an opaque background color, return that.
    if (!backgroundColor.hasAlpha())
        return backgroundColor;

Whenever background-color is not specified for option element it always returns after above statement because backgroundColor has values like m_color = 4294440951 (looks white color) and alpha() == 255.

I think HTMLOptionElement should take/inherit  the background-color from the HTMLSelectElement.
Please let me know any thoughts on this.

[Kent Tamura]

(In reply to comment #6)
> 1) In RenderMenuList::itemBackgroundColor() this function there is if checks as (line 475):
> 
>     // If the item has an opaque background color, return that.
>     if (!backgroundColor.hasAlpha())
>         return backgroundColor;
> 
> Whenever background-color is not specified for option element it always returns after above statement because backgroundColor has values like m_color = 4294440951 (looks white color) and alpha() == 255.
> 
> I think HTMLOptionElement should take/inherit  the background-color from the HTMLSelectElement.
> Please let me know any thoughts on this.

What are the behaviors of other browsers?

[Bákonyi Zsolt]

Other browsers are working well, even in windows and linux ( Firefox, Opera, IE ). Google Chrome beta was also good, but after changed to Chronium 15 on my Ubuntu 10.04LTS, this feature went wrong.

[Vineet Chaudhary (vineetc)]

(In reply to comment #8)
> Other browsers are working well, even in windows and linux ( Firefox, Opera, IE ). Google Chrome beta was also good, but after changed to Chronium 15 on my Ubuntu 10.04LTS, this feature went wrong.

More Specifically I tested for

Windows IE(7)    : Pass
Windows Chrome(14.0.835.163) : Pass
Windows Safari(5.1) : Pass
Windows/Linux Opera : Pass

Linux(ubuntu) Chrome(14.0.835.163) : FAILS

[Kent Tamura]

I see. So, probably popup-menu code for Chromium-Linux has a regression, and RenderMenuList is innocent.

[Kent Tamura]

(In reply to comment #9)
> Windows IE(7)    : Pass
> Windows Chrome(14.0.835.163) : Pass
> Windows Safari(5.1) : Pass
> Windows/Linux Opera : Pass
> 
> Linux(ubuntu) Chrome(14.0.835.163) : FAILS

What do you mean by "Pass"? Did the popup menu have black background and yellow foreground?

Mac Opera, Mac Chrome, Mac Safari showed a popup with white background and black foreground.

[Vineet Chaudhary (vineetc)]

(In reply to comment #11)
> (In reply to comment #9)
> > Windows IE(7)    : Pass
> > Windows Chrome(14.0.835.163) : Pass
> > Windows Safari(5.1) : Pass
> > Windows/Linux Opera : Pass
> > 
> > Linux(ubuntu) Chrome(14.0.835.163) : FAILS
> 
> What do you mean by "Pass"? Did the popup menu have black background and yellow foreground?
> 
> Mac Opera, Mac Chrome, Mac Safari showed a popup with white background and black foreground.

I tested for reduction test (attachment (id=110129)).
Pass for Black background and white text.

Fail as White background and white text.

[Vineet Chaudhary (vineetc)]

Created attachment 110497 [details]
proposed patch

Proposed patch.
Please let me know the review comments on this. 
I will update the patch with the test_case soon.

[Vineet Chaudhary (vineetc)]

Created attachment 110507 [details]
Updated patch

Updated patch with test case modified.

[Vineet Chaudhary (vineetc)]

(In reply to comment #10)
> I see. So, probably popup-menu code for Chromium-Linux has a regression, and RenderMenuList is innocent.

On debugging it is found that option element was getting the default value from themeChromiumLinux.css which has alpha() 255 so it was returning from RenderMenuList::itemBackgroundColor().

Please find the attached patch which fixes this issue now default color is set as rgba(247,247,247,0);
Regarding test case I have modified current test case manual-tests/item-background.html. 
The new behavior now matches with all other ports.

Please let me know your review comments.

[Kent Tamura]

Comment on attachment 110507 [details]
Updated patch

View in context: https://bugs.webkit.org/attachment.cgi?id=110507&action=review

> Source/WebCore/css/themeChromiumLinux.css:40
> -    background-color: #f7f7f7;
> +    background-color: rgba(247,247,247,0);

I don't think this is correct at all.
Why is it reasonable to make <option> transparent by default?
You have to find a real reason of the regression, and fix it.

> Source/WebCore/manual-tests/item-background.html:74
> -    <div class="swatch"></div>
> +    <div class="sblack"></div>

I understand this is expected color for other browsers.  How about Safari/Windows and Chromium/Windows?

[Vineet Chaudhary (vineetc)]

(In reply to comment #16)
> > Source/WebCore/css/themeChromiumLinux.css:40
> > -    background-color: #f7f7f7;
> > +    background-color: rgba(247,247,247,0);
 
> I don't think this is correct at all.
> Why is it reasonable to make <option> transparent by default?
> You have to find a real reason of the regression, and fix it.

I agree having <option> transparent by default is wrong but we set bgColor to #f7f7f7 ie. alpha as 1 then,
   if (!backgroundColor.hasAlpha())
        return backgroundColor;
this check will always pass n return and we wont be able set option elements color then.

Another approach we can do is in PopupListBox::paintRow(). Check for
backColor = m_popupClient->style()->visitedDependentColor(CSSPropertyBackgroundColor).blend(backgroundColor);

instead of backColor = style.backgroundColor();

//If you don't mind may I ping you on IRC?

> I understand this is expected color for other browsers.  How about Safari/Windows and Chromium/Windows?

Also for both Safari/Windows and Chromium/Windows expected color is black and blue.

[Vineet Chaudhary (vineetc)]

In bugzilla I found related bug https://bugs.webkit.org/show_bug.cgi?id=54115 

In which it is setting default color of option element to #f7f7f7 for linux.
So option element would never gets its parent's background-style.

[xiyuan]

This is actually fixed in https://bugs.webkit.org/show_bug.cgi?id=111873

*** This bug has been marked as a duplicate of bug 111873 ***