Prior to some change, presumably in Cocoa Widget color mapping, the table header rows in about:plugins used the text/selection highlight colors (light blue with black text, on my Mac). They currently use the menu highlight colors (a darker blue with bright white text). I'm really not sure what the color should be, though I find the new text hard to read. Since it is a table view, albeit a static one, one might expect the Aqua table headers (a la about:config)? The relevant snippet from plugins.css (the same in toolkit and xpfe, and unchanged for ages) is th { text-align: center; background-color: Highlight; color: HighlightText; which leads me to wonder what other places we might now be seeing the menu highlight instead of the text/selection highlight (and where the author actually intended for the latter to be used).

I think the css should be changed. Fwiw, see also bug 371609 (then the color will depend on your system selection color pref).

Per my comments in that bug, I think bug 371609 should be WONTFIXed, so this should definitely be addressed separately.

The patch in bug 371609 kind of restores the old behaviour, although now I get a dark graphite, whereas on Gecko 1.8 (both Fx and Camino) I get a light graphite. (graphite being my 'highlight' colour). But I don't think that is the correct colour/background colour choice for this case (a completely static table). At OS level, in iTunes, NetNewsWire, etc, only the header for the selected column in dynamic, sortable tables uses the highlight colour. The same goes for 'about:config'.

fwiw - Safari -> help menu > installed plugins. That UA uses medium grey for table-headers and light grey for table cells, #ccc and #f5f5f5 respectively, colour is set to black, #000.

I think all apps on all OS use the same file (the one in toolkit/content). So, changing the css will require that it looks OK on all OS. It might be hard arguing for a "special" mac plugins.css file, even though there is one in pinstripe/global.

If I'm understanding this correctly, the first question we need to answer is whether or not the Highlight color that we have set in Cocoa widgets is correct. If it is correct and we really want to fix this bug, then the next question is what do we want for a 'th' background-color. It sounds to me like our Highlight color is good right now, which first of all means this isn't a cocoa widget bug and secondly this no longer strikes me as a blocker. Changing components and blocking status to reflect that.

Yes, we're now separating the text selection color from the menu highlight color and menu highlight text color properly, AFAICT, and all of them are now set correctly in Cocoa widgets. Neither of those colors seem like good choices for table headers here, as philippe and Stefan have mentioned.

I don't see why table headers in this page should be connected to system highlight colour *at all*, but if they have to be, it definitely needs to be done properly :-p cl

JFTR, it's not really menu highlight - "Hightlight" is mapped to alternateSelectedControlColor which "Returns the system color used for the face of a selected control".