121738 - "navyblue" color converted to #0a0b0e instead of #a0b0e0

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect, P4)

Description

[yoav]

hey
the background color of the table data is black.

i'm using build 2001122106

Comment 1

[Boris Zbarsky [:bzbarsky]]

Attachment: minimal testcase

Comment 2

[Boris Zbarsky [:bzbarsky]]

What the hell is "navyblue" as a color?  It's not the same thing as "navy" in
Netscape 4.x....

Comment 3

[Boris Zbarsky [:bzbarsky]]

Attachment: Netscape 4.x screenshot

Comment 4

[Boris Zbarsky [:bzbarsky]]

IE5 does exactly what NS4 does.  In both, "navyblue" is #a0b0e0.  In mozilla
it's #0a0b0e (that's what DOM inspector claims the bgcolor attr is set to).  So
we're doing _something_ and it's almost right....  but not quite.

Comment 5

[Amarendra Hanumanula]

 Prioritizing this bug to P2.

Comment 6

[Chris Petersen]

Chnaging QA Contact

Comment 7

[Boris Zbarsky [:bzbarsky]]

The problem is in ComponentValue in nsColor.cpp...  it apparently uses a
different algorithm from the one that's used by NS4...

Comment 8

[Kevin McCluskey (gone)]

Reassigning to Don

Comment 9

[Amarendra Hanumanula]

adding testcase keyword

Comment 10

[dcone (gone)]

We do not support "navyblue".  We have "navy" in our lookup.. not "navyblue". 
Nav 4.x will take a color not supported and turn it into something.. probably 
some algorithm that converts the letters into a color.  Currenly.. we do what 
expolorer does.. and we ignore it.  This is not a bug.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Reopening.  Let me repeat again:

1)  Netscape parses "navyblue" into #a0b0e0
2)  IE parses "navyblue" into #a0b0e0
3)  Mozilla parses "navyblue" into #0a0b0e (in quirks mode)

I can assure you this is the case, as demonstrated by DOM inspector or simply
sticking printfs in ComponentValue().

All the browsers seem to break up navyblue as "nav" "ybl" "ue" and then parse
the three things separately as color specs for red, green, and blue.  All things
that are not valid hex are treated as 0 in all three.  So we get"

"0a0" "0b0" "0e"

At this point Mozilla takes the first two bytes of each block, giving #0a0b0e. 
Apparently IE and NS4 do something slightly different.

So we certainly do _not_ ignore the color spec (in quirks mode) and neither does
Explorer.

Comment 12

[dcone (gone)]

Does anyone use this.  The information I got from Marc Attinasi.. was that we do
not have to support.. but what we have in the lookup table. The tests Marc ran..
I think were using CSS because I saw explorer and mozilla ignore.. so that was a
mistake on my part.   I know we map to something.. but its effectivley ignoring
it.. or making up a color.  Is this something we really want to support, there
are better ways of putting color into a page than something like this.. right? 
We can use real RGB values right?  I think supporting something like this.. is
wrong, it tells the author.. go ahead.. put some quirky text in.. and a color..
will come out.. instead of telling the author.. go put the color in the right
way.  I personally dont think color should ever be supported this way.  

Comment 13

[Boris Zbarsky [:bzbarsky]]

Sure.  That's a much more coherent reason than "we don't parse that".  :)

Verified wontfix.

Comment 14

[Sinitsyn Valentine]

Hi,
I think this bug should be fixed, even if it is a little standarts uncompliant.
I've also found it at Repfusion Forums (http://www.repfusion.com/live) and I
think it's easier to fix algorithm of rendering colors (which makes the behavior
of Mozilla to be like the behavior of other browsers) than make every webmaster
of every site to convert his pages color to the right form.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Well...  This algorithm is used by a lot of different things (standards and
non-standards color parsing) so changes to it are kinda hard to do right.  I
tried the "obvious" solution and it ended up making all the Modern colors
purplish-reddish.... 

So it may in fact be easier to evangelize the one or two sites out there that
depend on this behavior.

Comment 16

[Boris Zbarsky [:bzbarsky]]

*** Bug 165276 has been marked as a duplicate of this bug. ***

Comment 17

[Boris Zbarsky [:bzbarsky]]

*** Bug 183921 has been marked as a duplicate of this bug. ***

Comment 18

[Hixie (not reading bugmail)]

*** Bug 204826 has been marked as a duplicate of this bug. ***

Comment 19

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'm not convinced this should really be wontfix.  However, it should be low
priority.

Comment 20

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

.

Comment 21

[Hixie (not reading bugmail)]

any idea what the algorithm is?

Comment 22

[Bill Mason]

*** Bug 211000 has been marked as a duplicate of this bug. ***

Comment 23

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

*** Bug 217191 has been marked as a duplicate of this bug. ***

Comment 24

[Harri Pesonen]

I stumbled into this. We have the following code:

<tr bgcolor=navyblue>
<td nowrap>some text</td>
</tr>

And the cell is almost black. In IE6 it is blue, and if changed to "navy" in
htm, then it becomes too dark in Firefox and IE6. So this is just a bug in
Mozilla, it converts "navyblue" to incorrect color. After reading the comments,
I still don't understand why something this simple can't be fixed.

Also when I saved the htm in Firefox to htm file, then the file got this
"#0a0b0e" instead of "navyblue", which is a bug as well.

Comment 25

[Harri Pesonen]

One more comment. This url
(http://www.htmlref.com/reference/appe/colorchart.htm) contains a list of common
browser colors. It says that navyblue should be #9FAFDF instead of #a0b0e0 or
#0a0b0e. What is more, navyblue seems to be the only color that is displayed
incorrectly in Firefox. It is discussed there as well:

"NOTE: While earlier versions of the Opera browser had highly inconsistent
support of color names, more recent releases (Opera 6 and Opera 7) are greatly
improved. Color names now display the same as their numerical equivalents in the
newer Opera browsers, with the single exception of navyblue. This color name
displays the same as navy in the Opera browsers. The color name navyblue is also
problematic in Netscape's browser versions 6 and 7, which display it as black."

Comment 26

[Harri Pesonen]

Sorry but one more comment: http://www.mountaindragon.com/html/colorsup.htm

"Other sources will add extra color names, adding in color names like
"navyblue." When most (but not all) browsers come across an unsupported color
name, they try to find a hexadecimal color code within the name presented.
Hexadecimal uses the numbers 0-9 and the letters A-F. Thus, in navyblue, most
browsers will see the A, the B and the E as hexadecimals, and convert the rest
of the letters to however many number of zeroes the browser needs to bring the
hexadecimal color code to a total of 6 digits. The result? Navyblue gets
rendered as A0B0E0, which is a rather light blue color. If you type in
"navygreen," you will get a darker blue: 0A00EE. It is by coincidence that
"navyblue" produces a bluish color, but not because it is an official color
name. Since not all browsers will interpret non-supported color names in this
manner, it is unwise to make up color names."

I think that "navyblue" should be added to color table, or the algorithm be fixed.

Comment 27

[Boris Zbarsky [:bzbarsky]]

Harri, there is no "navyblue" in the color table, nor should there be.

This bug _is_ about "fixing" the algorithm (where "fixing" means "doing exactly
what IE does, even if it's totally wacky").

Feel free to clearly spec out what IE _does_ do, so we can implement it.  So far
no one has done that.

Comment 28

[Harri Pesonen]

Yeah, but as someone else pointed out, "navyblue" had a correct value in
Netscape4, which Mozilla is based upon, and apparently IE also mimics Netscape.
So a bug was introduced at some point... now it seems that it would be easiest
to fix it by adding it to color table.

Comment 29

[Boris Zbarsky [:bzbarsky]]

*** Bug 253440 has been marked as a duplicate of this bug. ***

Comment 30

[timeless]

[e-mail]: to be clear as mud, navyblue is *not* the only case
where this turns up, it's just probably the most common. fixing the algorithm
means fixing the algorithm, not special casing navyblue.

Comment 31

[Elmar Ludwig]

*** Bug 299363 has been marked as a duplicate of this bug. ***

Comment 32

[Elmar Ludwig]

*** Bug 299363 has been marked as a duplicate of this bug. ***

Comment 33

[PikeUK]

Attachment: JS implementation of IE unknown colour algorithm

This is as far as I can tell what IE does with unknown colour values (with the
exception that it treats the empty string as either transparent or not-set).

Comment 34

[j.j.]

When changing the algorithm, make sure keyword "transparent" does what it means, like IE does. (bug 227072)

Comment 35

[Simon Pieters [:zcorpan]]

Some tests (I haven't figured out a working algorithm yet, probably also haven't tested all possible cases yet): http://simon.html5.org/test/html/parsing/color-attributes/

Comment 36

[Simon Pieters [:zcorpan]]

Test cases for the algorithm, along with the algorithm:

http://simon.html5.org/test/html/parsing/color-attributes/the-algorithm/

Comment 37

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The WhatWG HTML5 spec has the algorithm in detail:
http://www.whatwg.org/specs/web-apps/current-work/complete/common-microsyntaxes.html#rules-for-parsing-a-legacy-color-value
which will presumably fix both this and bug 227072.

Comment 38

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch to fix NS_LooseHexToRGB

This fixes the NS_LooseHexToRGB parts of implementing that algorithm in HTML5 (including ignoring 'transparent', which should fix bug 227072; the rest is for this bug).  It makes us pass all of the tests in http://simon.html5.org/test/html/parsing/color-attributes/the-algorithm/001.htm except for:
 * 206 and 245, which have sequences of multiple spaces in the values
 * 229, which has initial whitespace
 * 254-281, which test system colors
 * 284 (need to figure out why; looks like it ought to work)

I'd note that tests 283-284 should probably test the other combinations so as to check whether the truncation to 128 happens before or after the removal of '#'.

Comment 39

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

It looks like the HTML5 spec using the "legacy color value" algorithm for all presentational hint color values in the spec; the only use of the "simple color value" algorithm is for the colorpicker form control.

Comment 40

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch 2: implement the string-to-RGB part of the HTML5 algorithm

patch 1 is in bug 227072.

Comment 41

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch 3: do loose color parsing in all modes, per HTML5

Comment 42

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch 4: add comment about system colors

Comment 43

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch 5: add comment about whitespace

(Still waiting to hear if I can use zcorpan's tests or if I'll have to write my own.)

Comment 44

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 446917 [details] [diff] [review]
patch 3: do loose color parsing in all modes, per HTML5

I need to revise this one to avoid:

25138 ERROR TEST-UNEXPECTED-FAIL | /tests/content/base/test/test_bug493881.html | element's style changed by setting legacy prop to undefined - got "rgb(0, 239, 14)", expected "rgb(0, 0, 0)"
25140 ERROR TEST-UNEXPECTED-FAIL | /tests/content/base/test/test_bug493881.html | element's style changed by setting legacy prop to undefined - got "rgb(0, 239, 14)", expected "rgb(0, 0, 238)"
25141 ERROR TEST-UNEXPECTED-FAIL | /tests/content/base/test/test_bug493881.html | element's style changed by setting legacy prop to undefined - got "rgb(0, 239, 14)", expected "rgb(0, 0, 238)"

Comment 45

[Simon Pieters [:zcorpan]]

(In reply to comment #35)
> Some tests (I haven't figured out a working algorithm yet, probably also
> haven't tested all possible cases yet):
> http://simon.html5.org/test/html/parsing/color-attributes/

(In reply to comment #36)
> Test cases for the algorithm, along with the algorithm:
> 
> http://simon.html5.org/test/html/parsing/color-attributes/the-algorithm/

Apparently I also had newer tests at http://simon.html5.org/specs/html-color-attributes/

You can use these under any license you want.

Comment 46

[Simon Pieters [:zcorpan]]

(In reply to comment #45)
> (In reply to comment #35)
> > Some tests (I haven't figured out a working algorithm yet, probably also
> > haven't tested all possible cases yet):
> > http://simon.html5.org/test/html/parsing/color-attributes/
> 
> (In reply to comment #36)
> > Test cases for the algorithm, along with the algorithm:
> > 
> > http://simon.html5.org/test/html/parsing/color-attributes/the-algorithm/
> 
> Apparently I also had newer tests at
> http://simon.html5.org/specs/html-color-attributes/

Sorry, wrong URL: http://simon.html5.org/test/html/rendering/color-attributes/
 

> You can use these under any license you want.

Comment 47

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 446918 [details] [diff] [review]
patch 4: add comment about system colors

FWIW, I don't really think you need a separate review request for this :)

Comment 48

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 446919 [details] [diff] [review]
patch 5: add comment about whitespace

I say, do what you think makes sense, especially if that matches webkit. That gives us a good case for getting the spec modified.

Comment 49

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

http://hg.mozilla.org/mozilla-central/rev/fae3332168ec
http://hg.mozilla.org/mozilla-central/rev/72d5643b58d9
http://hg.mozilla.org/mozilla-central/rev/f5d42b609b23
http://hg.mozilla.org/mozilla-central/rev/ddb5d662589b
http://hg.mozilla.org/mozilla-central/rev/bcff82f83a54

Comment 50

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

I updated <https://developer.mozilla.org/en/Mozilla_Quirks_Mode_Behavior> and <https://developer.mozilla.org/en/HTML/HTML5>. Not sure if anything else needs to be updated.

Comment 51

[Eric Shepherd [:sheppy]]

I think that's good enough.

Comment 52

[Yuhong Bao]

The reason from http://mxr.mozilla.org/classic/source/lib/layout/layimage.c#155 :
while ((red_val > 255)||(green_val > 255)||(blue_val > 255))
{
	red_val = (red_val >> 4);
	green_val = (green_val >> 4);
	blue_val = (blue_val >> 4);
}
Notice after they parse the components as a 32-bit integer, they *divide* each component by 16 until it fits into a 8-bit integer. This is why leading zeros are ignored.