Bug 10058 – REGRESSION: Font color in pull-down menus not correct when WebKit themed

• Component: Forms
• Status: NEW

[Leland Scott]

I've been using a dark theme through ShapeShifter the last few weeks, and I noticed that WebKit behaves differently from Safari in the font color for pulldown menus.  The color is supposed to be white, since that's what's defined as the "inner control" font color in the theme, but the font displays as black instead.  Against a black form widget, this renders it illegible.  This affects all pull-down menus on all web pages, and also some (but not all) buttons.

On this form, the four pull-down menus above, and the three buttons below cannot be read.  When I select the pull-down menu, I can then read the choices, but not until then.  This is major only because it makes WebKit unusable to anyone using ShapeShifter with a dark theme.

[Leland Scott]

Created attachment 9608 [details]
I'm attaching a couple of screenshots to demonstrate.

This screenshot shows a page from the Apple store.

[Leland Scott]

Created attachment 9609 [details]
Attachment shows the Bugzilla submission form on this site.

[Alexey Proskuryakov]

Regression->P1, but I don't have ShapeShifter to confirm.

I think this is INVALID, but see also bug 9926. As a workaround, you can use a user stylesheet to override the color of <option> elements.

[Alexey Proskuryakov]

Created attachment 9614 [details]
test case

Does this fail in the same way?

[Alexey Proskuryakov]

From Mitz via IRC: "html4.css has input, textarea, select, button { ... color: initial ... } <...> it all comes down to not wanting to add a foreground color attributed to the attributed string in order to maintain the highlighting behavior."

The computation of the initial color (and font?) should probably use theme properties, but looks like this is blocked by bug 9769.

[Leland Scott]

(In reply to comment #5)
> Created an attachment (id=9614) [edit]
> test case
> 
> Does this fail in the same way?
> 

Yes, it does.  I can see the green color when highlighting the option.  It's the initial color, and the selected color, that's the problem.  The initial color should not always be black, and the  color of the selected option seems to revert to the initial color when selected.  When highlighted, the colors are fine (white, green).

[Leland Scott]

(In reply to comment #3)
> Regression->P1, but I don't have ShapeShifter to confirm.
> 

Highly recommend you download a trial of ShapeShifter for testing WebKit.  Lots of users, lots of themes out there.  http://www.unsanity.com/haxies/shapeshifter

This is not a problem for any of the other Webkit-based browsers I use regularly (Safari, OmniWeb, Shiira), and it only showed up in WebKit nightly fairly recently.  WebKit needs to be theme-friendly, as ShapeShifter is the only way Safari users have of applying themes, which are of course taken for granted by Firefox and Opera users.

[Dave Hyatt]

In AppKit terminology, what is this color?  How can we obtain it from the system?  Is there a standard "popup control color" that can be accessed via Objective-C?

[Rosyna]

Well, Carbon has the color ;)

Otherwise -[NSColor controlTextColor] for the text in the popup button, since it is a control. -[NSColor alternateSelectedControlColor] is the color of the text of a control that is being clicked on. -selectedMenuItemTextColor for selected menu items.

-[NSColor controlTextColor] is the control color for the widgets shown with the incorrect text color in these screenshots.

[Rosyna]

I meant alternateSelectedControlTextColor not alternateSelectedControlColor for the clicked on control color.

[Dave Hyatt]

Ok, cool.  Solution is to make some new system color extensions, e.g., -webkit-control-color, and then have the theme give back the correct color to use.

[Joost de Valk (AlthA)]

Who should make those Dave? WebKit devs or Unsanity? :)

[Stephanie Lewis]

Radar <rdar://problem/4959689>

[Maciej Stachowiak]

Haxies are not supported by WebKit, so this shouldn't be a P1.