Closed Bug 121738 Opened 23 years ago Closed 14 years ago

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

Categories

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

Product:
Core
Component:
CSS Parsing and Computation
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9.3a5

People

(Reporter: stakadush, Assigned: dbaron)

References

(
URL
)

Details

(Keywords: dev-doc-complete, testcase)

Attachments

(7 files, 1 obsolete file)

minimal testcase
256 bytes, text/html
Details
Netscape 4.x screenshot
17.26 KB, image/png
Details
JS implementation of IE unknown colour algorithm
5.30 KB, text/html
Details
patch 2: implement the string-to-RGB part of the HTML5 algorithm
4.40 KB, patch
sicking
: review+
Details | Diff | Splinter Review
patch 3: do loose color parsing in all modes, per HTML5
936 bytes, patch
sicking
: review+
Details | Diff | Splinter Review
patch 4: add comment about system colors
952 bytes, patch
sicking
: review+
Details | Diff | Splinter Review
patch 5: add comment about whitespace
1.02 KB, patch
sicking
: review-
Details | Diff | Splinter Review 
hey
the background color of the table data is black.

i'm using build 2001122106
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
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
 Prioritizing this bug to P2.
Priority: -- → P2
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...
Target Milestone: --- → mozilla1.1
Reassigning to Don
Assignee: attinasi → dcone
adding testcase keyword
Keywords: testcase
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
Closed: 23 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 → ---
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
Closed: 23 years ago → 23 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
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. ***
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: dcone → dbaron
Status: REOPENED → NEW
QA Contact: amar → ian
any idea what the algorithm is?
*** Bug 211000 has been marked as a duplicate of this bug. ***
*** Bug 217191 has been marked as a duplicate of this bug. ***
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.
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."
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.
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. ***
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.
*** Bug 299363 has been marked as a duplicate of this bug. ***
*** Bug 299363 has been marked as a duplicate of this bug. ***
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).
When changing the algorithm, make sure keyword "transparent" does what it means, like IE does. (bug 227072)
Assignee: dbaron → nobody
QA Contact: ian → style-system
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/
Test cases for the algorithm, along with the algorithm:

http://simon.html5.org/test/html/parsing/color-attributes/the-algorithm/
Assignee: nobody → dbaron
Attached patch patch to fix NS_LooseHexToRGB (obsolete) — — Splinter Review 
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 '#'.
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.
(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)
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)"
(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.
(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 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+
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.
I think that's good enough.
Keywords: dev-doc-needed → dev-doc-complete
Flags: in-testsuite+
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.

Attachment

General

Creator:
Created:
Updated:
Size: