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.
Created attachment 110127 [details] The bug itself
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.
Old bugzilla reference : https://bugs.webkit.org/show_bug.cgi?id=9846
Yes, looks like a duplicate of bug 9846. *** This bug has been marked as a duplicate of bug 9846 ***
Actually, we still need separate bugs for different platforms, so not tracking as duplicate.
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.
(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?
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.
(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
I see. So, probably popup-menu code for Chromium-Linux has a regression, and RenderMenuList is innocent.
(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.
(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.
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.
Created attachment 110507 [details] Updated patch Updated patch with test case modified.
(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.
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?
(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.
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.
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 ***