308214 - Firefox writes colors in rgb(255,255,255) format rather than hex code when using javascript color picker

Status: NEW

(Core :: DOM: Core & HTML, defect, P5)

Description

[Ryan]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
Build Identifier: Mozilla/5.0

In the BETA release of FireFox, the browser will automatically "write" the 
colors as rgb(255, 255, 255) format rather than #FFFFFF. To see this, you may 
need to create a trial account with our services. If you are within our site 
manager, and you got to Appearance > Appearance Options > Site Colors and use 
the Color Picker there, you will see that it writes the color into the text 
box in rgb format rather then hexidecimal. This shows as black on the client's 
site rather than the actual color they wanted to pick.

Reproducible: Always

Steps to Reproduce:
IN BETA RELEASE OF NEW FIREFOX
1. Create a trial account with our services. (takes 20 seconds and you can use 
dummy information.)
2. go to Appearance > Appearance Options > Site Colors
3. Click on the color picker link - select a color.

Actual Results:  
Inside the textbox where it should automatically fill in the hexidecimal of 
the color the client chooses, it writes it in rgb(000, 000, 000)

Expected Results:  
Write the colors in hexidecimal format. [#FFFFFF]

Comment 1

[Jo Hermans]

test-account : username dummy, password dummy

this sites generateds hundreds and hundreds of warnings in the JavaScript Console

Comment 2

[Ryan]

The javascript warnings are definetly not on our side. We've checked our site 
thousands of times using many different browsers, varying from IE, to 
netscape, Opera, even Safari - and encountered VERY little problems. This is 
the first actual problem we've run into using FireFox, and hopefully this will 
be addressed in the final release - seeing as how 23% of our clients use 
FireFox.

Comment 3

[Gabriel Sjoberg]

The statement in comment #1 isn't exaggerating.  This site's JavaScript code has
way too many problems.

To the original reporter: Please fix your JavaScript code and post here when you
have done so.  Alternatively, provide a simplified testcase that developers can
use to diagnose the problem.

Comment 4

[Ryan]

There are no problems with our site. Opera, Safari, and IE read this site 
perfectly fine. We have always had problems with Firefox, even the REAL 
firefox [not beta] - it's just the fact that the beta release is screwing up 
our customer's pages so badly, that it is becoming a hassle to get a tech. 
call every 5 seconds because somebody is using your browser which apparently 
doesn't read javascript like any other decent browser. Why is your browser 
writing in rgb(255, 255, 255) format rather than hex? - make sure you are 
using the beta version when you try this out.

Comment 5

[Gabriel Sjoberg]

Visit the page using the latest build of Firefox.  After selecting a color and
clicking on "Save Color", go to Tools > JavaScript Console.  You will see a
large number of errors and warnings about the color picker.  Your software is
outdated; you need to either update it or modify the source yourself to conform
to the huge number of changes in JavaScript that have occurred since it was written.

Comment 6

[Jo Hermans]

(In reply to comment #4)
> Why is your browser writing in rgb(255, 255, 255) format rather than hex?

see bug 7046 for an explanation

Comment 7

[Jo Hermans]

and bug 268405

Comment 8

[PikeUK]

Reporter, your first post seems to imply this is a regression in the beta,
however my tests showed the same behaviour seems to happen in Firefox 1.06.
Could you clarify whether this is something new or not (the bugs linked in
comments 6 and 7 imply it's not)?

->Core:DOM

Comment 9

[Ryan]

http://news.com.com/Hackers+work+to+exploit+latest+Firefox+flaw/2100-1002_3-
5863451.html?tag=cd.top

All I have to say.

Comment 10

[Anne (:annevk)]

Returning them as #aabbcc would be consistent with the canvas API. See also bug
110762 comment 18. I assume this will be made more formal in the CSS OM,
whenever that comes.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Jo, Gabriel, it DOES NOT MATTER whether script on a site has warnings if they're not relevant to the bug being reported.  Which these are not.  Comments like comment 3 are really just not acceptable (re: the "fix your javascript" part).

Comment 12

[Boris Zbarsky [:bzbarsky]]

So based on bug 110762 comment 18 it sounds like Ian, at least, supports switching to the #rrggbb format for CSS colors.  This is a simple change technically; the question is what it would break (esp. since we're not likely to make that change in 1.8 at this point).  We've been shipping the rgb() serialization for years now.

I did check that our chrome doesn't seem to rely on this serialization, at least at first glance...

Thoughts?

Comment 13

[Boris Zbarsky [:bzbarsky]]

Actually, changing this _might_ break editor.  Not sure.  See string compares in nsHTMLCSSUtils::IsCSSEquivalentToHTMLInlineStyleSet.  Daniel, would this be an issue for those?

Comment 14

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

I'm a little wary of switching to #RRGGBB since we can never change the behaviour of old releases. There is a big risk that if we change then authors will drop support for 1.0.x and 1.5.x browsers.

That said, i think it would have been better if we had returned #RRGGBB all along, and I'm fine with switching if we really want to.

Comment 15

[Brendan Eich [:brendan]]

Is there any way we could notice that the format we've shipped for years is wanted instead of #rrggbb?

/be

Comment 16

[Boris Zbarsky [:bzbarsky]]

Not that I can see -- the code just knows someone wants a string out of it; to tell what people expect we'd need to figure out what they're doing with that string afterward (that is, say, how they're parsing it to get the individual color components).

Comment 17

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

(In reply to comment #13)
> Actually, changing this _might_ break editor.  Not sure.  See string compares
> in nsHTMLCSSUtils::IsCSSEquivalentToHTMLInlineStyleSet.  Daniel, would this be
> an issue for those?

Yes it would. And it would be an issue for all clients relying on that current
behavior since it never changed.

I suggest we don't touch it at all, and provide an extension to the CSS OM able
to convert return types (yes, I know, CSSValue was originally meant to do that
but it's barely implemented...).

Comment 18

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.