977063 - Colors that are part of font family names are not shown as text in DevTools Inspector/Rules

Status: RESOLVED DUPLICATE of bug 971234

(DevTools :: Inspector, defect)

Description

[Matvey]

Attachment: arial-black-inspector-display.png

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release)
Build ID: 20140218122424

Steps to reproduce:

Had the following rule in my CSS:

h1{font-family:'Arial Black', Arial, sans-serif;}


Actual results:

When inspecting the element, I noticed that 'Black' inside single-quoted font family name 'Arial Black' is being shown as a black circle and RGB color next to it, with my devtools settings, it was #000.


Expected results:

The rule should display with 'Arial Black' being 'Arial Black'.

Comment 1

[Matvey]

Attachment: testcase-single-double-quotes-etc.html

Added an HTML-testcase which shows that the bug doesn't happen when font-family name is wrapped in double quotes, but happens inside single quotes.

Comment 2

[nmckenz]

I successfully re-created the CSS rule [font-family: 'Arial Black'] in an html page using [FF:v28]. It did show up in the Webdev inspector tool as a black circle with the RGB color code next to it. But it also did this for color rules with no quotes. See the code I used to test below:

<style type="text/css">
body {
    color: purple;
    background-color: #d8da3d;
    font-family: 'Arial Black' ,Arial,sans-serif; }
</style>

I don't believe its an error though. If you create a page using this sample code and use the Webdev inspector tool hopefully you'll see what i mean. It seems to me that it's just a "feature" of the inspector tool to display the style sheet color rules differently when you use [single quotes] vs [double quotes].

Comment 3

[nmckenz]

@Matvey: I decided to test the sample code i suggested in the comment above, in Debian [Wheezy]7.4 using Firefox Nightly & on Windows 8 using FireFox Nightly 31.0a1. On both platforms it displayed in the Webdev inspector tool closer to how you stated it should look in your expected results using [single quotes]. So the rule (font-family: 'Arial Black' ,Arial,sans-serif;) showed up as [font-family: "Arial Black",Arial,sans-serif;] it did not display as a black circle with the RGB color next to it. So i stand corrected about it not being an error, it seems as if this issue has been resolved in the newer versions of Firefox.

Comment 4

[Patrick Brosset <:pbro>]

We fixed the parsing phase in the rule-view recently, so anything within quotes (single or double) is not going to be parsed as a color anymore normally.
However, if you have `font-family: Arial black` (no quotes at all), then we still will show black as a color.
So this bug is still valid for this usecase.

Comment 5

[Patrick Brosset <:pbro>]

Conversation with bz on IRC:

< bz> So we could check whether the property has a color as a valid value
< bz> That seems like it would address the issue, no?
< pbrosset> yes
< bz> We could add an API for that on inIDOMUtils
< pbrosset> that would be pretty useful
< bz> One can abuse getCSSValuesForProperty for this (see if the color in question is in the list) but that does a lot more work than would a check for whether color is a valid value type
< bz> pbrosset: Please file a bug describing what sort of API would be most useful to you here and assign to me?
< pbrosset> we'd still have to parse the value string to find out whether there is a color at all and where it is.
< bz> Yes, indeed
< pbrosset> wouldn't there be cases where the value contains both colors and free text parts
< pbrosset> potentially resembling colors
< pbrosset> I can't think of any property where that's the case though
< bz> Generally that would make the property hard to parse
< bz> so url() and stuff inside "" get different treatment, good
< bz> And stuff outside those constructs would generally be ambiguous if it allowed both text (or even just identifiers) and colors
< bz> So wouldn't happen
< bz> "animation-name: black" has the same issue, not surprisingly.  ;)

Comment 6

[Patrick Brosset <:pbro>]

I've been playing a little bit with the new APIs i inDOMUtils (needed it for another bug). Note that:

- to check whether a property supports colors, you'll need to test for 2 things:
DOMUtils.cssPropertySupportsType(name, DOMUtils.TYPE_COLOR)
and
DOMUtils.cssPropertySupportsType(name, DOMUtils.TYPE_GRADIENT)

- this function doesn't return true for
DOMUtils.cssPropertySupportsType("box-shadow", DOMUtils.TYPE_COLOR)
whereas box-shadows may have colors in them.

Comment 7

[Tim Nguyen :ntim]

I suggest we just disable color parsing for font and animation properties.

We don't need color parsing for fonts, since keywords like font: menu are being misparsed as font: #F0F0F0 (while the color of the text is actually non-dependent of the font property, besides, the text is actually shown black with no other styles).
Also, -moz- keywords should just be kept unparsed since they vary across platforms and themes.

As for animation, we don't need color parsing, and I'm pretty sure of that.

Comment 8

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

(In reply to Tim Nguyen [:ntim] from comment #7)
> I suggest we just disable color parsing for font and animation properties.
> 
> We don't need color parsing for fonts, since keywords like font: menu are
> being misparsed as font: #F0F0F0 (while the color of the text is actually
> non-dependent of the font property, besides, the text is actually shown
> black with no other styles).
> Also, -moz- keywords should just be kept unparsed since they vary across
> platforms and themes.
> 
> As for animation, we don't need color parsing, and I'm pretty sure of that.

We plan to use domUtils.cssPropertySupportsType() to decide how each property is to be parsed... simple and accurate.

Comment 10

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

For now, disable color parsing for font and animation properties is the simplest solution.