The default bug view has changed. See this FAQ.

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

RESOLVED FIXED in mozilla1.9.3a5

Status

()

Core
CSS Parsing and Computation
P4
normal
RESOLVED FIXED
15 years ago
4 years ago

People

(Reporter: yoav, Assigned: dbaron)

Tracking

({dev-doc-complete, testcase})

Trunk
mozilla1.9.3a5
dev-doc-complete, testcase
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(7 attachments, 1 obsolete attachment)

(Reporter)

Description

15 years ago
hey
the background color of the table data is black.

i'm using build 2001122106
Created attachment 66423 [details]
minimal testcase
What the hell is "navyblue" as a color?  It's not the same thing as "navy" in
Netscape 4.x....
Assignee: karnaze → attinasi
Status: UNCONFIRMED → NEW
Component: HTMLTables → Layout
Ever confirmed: true
OS: Windows 2000 → All
QA Contact: amar → petersen
Hardware: PC → All
Created attachment 66425 [details]
Netscape 4.x screenshot
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.
Summary: black td → "navyblue" color converted to #0a0b0e instead of #a0b0e0

Comment 5

15 years ago
 Prioritizing this bug to P2.
Priority: -- → P2

Comment 6

15 years ago
Chnaging QA Contact
QA Contact: petersen → amar
The problem is in ComponentValue in nsColor.cpp...  it apparently uses a
different algorithm from the one that's used by NS4...

Updated

15 years ago
Target Milestone: --- → mozilla1.1
Reassigning to Don
Assignee: attinasi → dcone

Comment 9

15 years ago
adding testcase keyword
Keywords: testcase

Comment 10

15 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → INVALID
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.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---

Comment 12

15 years ago
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.  
Status: REOPENED → RESOLVED
Last Resolved: 15 years ago15 years ago
Resolution: --- → WONTFIX
Target Milestone: mozilla1.1 → Future
Sure.  That's a much more coherent reason than "we don't parse that".  :)

Verified wontfix.
Status: RESOLVED → VERIFIED

Comment 14

15 years ago
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.
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.
*** Bug 165276 has been marked as a duplicate of this bug. ***
*** Bug 183921 has been marked as a duplicate of this bug. ***
*** Bug 204826 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 19

14 years ago
I'm not convinced this should really be wontfix.  However, it should be low
priority.
Status: VERIFIED → REOPENED
Component: Layout → Style System
Priority: P2 → P4
Resolution: WONTFIX → ---
(Assignee)

Comment 20

14 years ago
.
Assignee: dcone → dbaron
Status: REOPENED → NEW
QA Contact: amar → ian
any idea what the algorithm is?

Comment 22

14 years ago
*** Bug 211000 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 23

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

Comment 24

13 years ago
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

13 years ago
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

13 years ago
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.
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

13 years ago
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.
*** Bug 253440 has been marked as a duplicate of this bug. ***

Comment 30

13 years ago
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

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

Comment 32

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

Comment 33

12 years ago
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

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

Updated

10 years ago
Assignee: dbaron → nobody
QA Contact: ian → style-system

Comment 35

10 years ago
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

10 years ago
Test cases for the algorithm, along with the algorithm:

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

Comment 37

7 years ago
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.
(Assignee)

Updated

7 years ago
Assignee: nobody → dbaron
(Assignee)

Comment 38

7 years ago
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 '#'.
(Assignee)

Comment 39

7 years ago
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.
(Assignee)

Comment 40

7 years ago
Created attachment 446916 [details] [diff] [review]
patch 2: implement the string-to-RGB part of the HTML5 algorithm

patch 1 is in bug 227072.
Attachment #446899 - Attachment is obsolete: true
Attachment #446916 - Flags: review?(jonas)
(Assignee)

Comment 41

7 years ago
Created attachment 446917 [details] [diff] [review]
patch 3: do loose color parsing in all modes, per HTML5
Attachment #446917 - Flags: review?(jonas)
(Assignee)

Comment 42

7 years ago
Created attachment 446918 [details] [diff] [review]
patch 4: add comment about system colors
Attachment #446918 - Flags: review?(jonas)
(Assignee)

Comment 43

7 years ago
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.)
Attachment #446919 - Flags: review?(jonas)
(Assignee)

Comment 44

7 years ago
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)"

Updated

7 years ago
Blocks: 475191

Comment 45

7 years ago
(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

7 years ago
(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.
Attachment #446916 - Flags: review?(jonas) → review+
Attachment #446917 - Flags: review?(jonas) → review+
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 :)
Attachment #446918 - Flags: review?(jonas) → review+
Attachment #446919 - Flags: review?(jonas) → review-
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.
(Assignee)

Comment 49

7 years ago
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
Status: NEW → RESOLVED
Last Resolved: 15 years ago7 years ago
Resolution: --- → FIXED
Target Milestone: Future → mozilla1.9.3a5
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.
Keywords: dev-doc-needed
I think that's good enough.
Keywords: dev-doc-needed → dev-doc-complete

Updated

7 years ago
Flags: in-testsuite+

Comment 52

4 years ago
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.
You need to log in before you can comment on or make changes to this bug.