Last Comment Bug 121738 - "navyblue" color converted to #0a0b0e instead of #a0b0e0
: "navyblue" color converted to #0a0b0e instead of #a0b0e0
Status: RESOLVED FIXED
: dev-doc-complete, testcase
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: Trunk
: All All
: P4 normal (vote)
: mozilla1.9.3a5
Assigned To: David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
:
Mentors:
http://www.sqlteam.com/Forums/registe...
: 165276 183921 211000 217191 253440 299363 (view as bug list)
Depends on:
Blocks: 475191
  Show dependency treegraph
 
Reported: 2002-01-24 17:30 PST by yoav
Modified: 2013-02-02 12:51 PST (History)
16 users (show)
Ms2ger: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
minimal testcase (256 bytes, text/html)
2002-01-24 23:08 PST, Boris Zbarsky [:bz] (Out June 25-July 6)
no flags Details
Netscape 4.x screenshot (17.26 KB, image/png)
2002-01-24 23:22 PST, Boris Zbarsky [:bz] (Out June 25-July 6)
no flags Details
JS implementation of IE unknown colour algorithm (5.30 KB, text/html)
2005-07-02 10:23 PDT, PikeUK
no flags Details
patch to fix NS_LooseHexToRGB (5.47 KB, patch)
2010-05-22 11:17 PDT, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
no flags Details | Diff | Review
patch 2: implement the string-to-RGB part of the HTML5 algorithm (4.40 KB, patch)
2010-05-22 14:12 PDT, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
jonas: review+
Details | Diff | Review
patch 3: do loose color parsing in all modes, per HTML5 (936 bytes, patch)
2010-05-22 14:13 PDT, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
jonas: review+
Details | Diff | Review
patch 4: add comment about system colors (952 bytes, patch)
2010-05-22 14:13 PDT, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
jonas: review+
Details | Diff | Review
patch 5: add comment about whitespace (1.02 KB, patch)
2010-05-22 14:14 PDT, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
jonas: review-
Details | Diff | Review

Description yoav 2002-01-24 17:30:19 PST
hey
the background color of the table data is black.

i'm using build 2001122106
Comment 1 Boris Zbarsky [:bz] (Out June 25-July 6) 2002-01-24 23:08:35 PST
Created attachment 66423 [details]
minimal testcase
Comment 2 Boris Zbarsky [:bz] (Out June 25-July 6) 2002-01-24 23:09:16 PST
What the hell is "navyblue" as a color?  It's not the same thing as "navy" in
Netscape 4.x....
Comment 3 Boris Zbarsky [:bz] (Out June 25-July 6) 2002-01-24 23:22:17 PST
Created attachment 66425 [details]
Netscape 4.x screenshot
Comment 4 Boris Zbarsky [:bz] (Out June 25-July 6) 2002-01-24 23:24:23 PST
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 2002-01-25 12:11:27 PST
 Prioritizing this bug to P2.
Comment 6 Chris Petersen 2002-01-25 12:44:50 PST
Chnaging QA Contact
Comment 7 Boris Zbarsky [:bz] (Out June 25-July 6) 2002-01-25 13:20:55 PST
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) 2002-01-28 16:11:00 PST
Reassigning to Don
Comment 9 Amarendra Hanumanula 2002-02-15 18:16:21 PST
adding testcase keyword
Comment 10 dcone (gone) 2002-02-18 13:20:46 PST
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 [:bz] (Out June 25-July 6) 2002-02-18 17:59:48 PST
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) 2002-02-18 19:07:37 PST
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 [:bz] (Out June 25-July 6) 2002-02-18 19:11:01 PST
Sure.  That's a much more coherent reason than "we don't parse that".  :)

Verified wontfix.
Comment 14 Sinitsyn Valentine 2002-02-18 23:10:51 PST
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 [:bz] (Out June 25-July 6) 2002-02-19 09:06:08 PST
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 [:bz] (Out June 25-July 6) 2002-08-29 02:17:04 PDT
*** Bug 165276 has been marked as a duplicate of this bug. ***
Comment 17 Boris Zbarsky [:bz] (Out June 25-July 6) 2002-12-06 09:02:10 PST
*** Bug 183921 has been marked as a duplicate of this bug. ***
Comment 18 Hixie (not reading bugmail) 2003-05-08 07:02:01 PDT
*** Bug 204826 has been marked as a duplicate of this bug. ***
Comment 19 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-05-08 10:52:05 PDT
I'm not convinced this should really be wontfix.  However, it should be low
priority.
Comment 20 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-05-08 10:56:24 PDT
.
Comment 21 Hixie (not reading bugmail) 2003-05-08 10:59:20 PDT
any idea what the algorithm is?
Comment 22 Bill Mason 2003-06-28 11:22:39 PDT
*** Bug 211000 has been marked as a duplicate of this bug. ***
Comment 23 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-08-24 22:24:34 PDT
*** Bug 217191 has been marked as a duplicate of this bug. ***
Comment 24 Harri Pesonen 2004-08-19 04:04:49 PDT
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 2004-08-19 04:41:33 PDT
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 2004-08-19 04:52:54 PDT
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 [:bz] (Out June 25-July 6) 2004-08-19 12:19:21 PDT
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 2004-08-19 23:56:51 PDT
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 [:bz] (Out June 25-July 6) 2004-09-05 00:12:25 PDT
*** Bug 253440 has been marked as a duplicate of this bug. ***
Comment 30 timeless 2004-09-05 02:46:32 PDT
harri.pesonen@wicom.com: 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 2005-07-01 04:32:36 PDT
*** Bug 299363 has been marked as a duplicate of this bug. ***
Comment 32 Elmar Ludwig 2005-07-01 04:34:25 PDT
*** Bug 299363 has been marked as a duplicate of this bug. ***
Comment 33 PikeUK 2005-07-02 10:23:14 PDT
Created attachment 188040 [details]
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. 2006-12-28 11:28:29 PST
When changing the algorithm, make sure keyword "transparent" does what it means, like IE does. (bug 227072)
Comment 35 Simon Pieters 2007-07-03 05:44:42 PDT
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 2007-08-23 10:10:21 PDT
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-7 (review requests must explain patch) 2010-05-22 09:27:10 PDT
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-7 (review requests must explain patch) 2010-05-22 11:17:14 PDT
Created attachment 446899 [details] [diff] [review]
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-7 (review requests must explain patch) 2010-05-22 11:46:04 PDT
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-7 (review requests must explain patch) 2010-05-22 14:12:16 PDT
Created attachment 446916 [details] [diff] [review]
patch 2: implement the string-to-RGB part of the HTML5 algorithm

patch 1 is in bug 227072.
Comment 41 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2010-05-22 14:13:24 PDT
Created attachment 446917 [details] [diff] [review]
patch 3: do loose color parsing in all modes, per HTML5
Comment 42 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2010-05-22 14:13:49 PDT
Created attachment 446918 [details] [diff] [review]
patch 4: add comment about system colors
Comment 43 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2010-05-22 14:14:25 PDT
Created attachment 446919 [details] [diff] [review]
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-7 (review requests must explain patch) 2010-05-22 16:33:08 PDT
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 2010-05-23 13:52:22 PDT
(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 2010-05-23 13:54:00 PDT
(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) PTO Until July 5th 2010-05-25 14:09:42 PDT
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) PTO Until July 5th 2010-05-25 14:11:03 PDT
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 50 :Ms2ger 2010-06-05 05:13:57 PDT
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] 2010-06-15 13:55:19 PDT
I think that's good enough.
Comment 52 Yuhong Bao 2013-02-02 12:51:42 PST
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.

Note You need to log in before you can comment on or make changes to this bug.