User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008070400 SUSE/3.0.1-0.1 Firefox/3.0.1 Build Identifier: http://chatzilla.hacksrus.com/xpi/chatzilla-0.9.83.xpi I am using this motif http://www.hacksrus.com/~ginda/chatzilla/motifs/output-light-faces.css on #chatzilla , and I can only see faces when the nickname is entirely lower-case. This happened after upgrading to Firefox 3, it worked as expected with Firefox 2 Reproducible: Always Steps to Reproduce: 1. Select http://www.hacksrus.com/~ginda/chatzilla/motifs/output-light-faces.css as motif for #chatzilla 2. Notice face pictures appear when using lower case nickname 3. Notice face picture disappears when using mixed case nickname Actual Results: Pictures of faces disappears when using mixed case nicknames (like JanE) Expected Results: The same picture should appear for "JanE" as for "jane" This worked well in Firefox 2 and before.

This is Firefox's fault.

This one is fun. The CSS Spec says that the case-sensitivity depends on the document language. We're specifying xhtml, but get parsed as html. HTML is case insensitive, whereas XHTML is not. So even though we're parsed as HTML, we're being treated as XHTML (assuming that's why it's not working). Isn't the web fun? :D

Each sample of text should of course be blue.

Comment on attachment 339764 [details] Test case Oops, ticked the wrong box ;-)

But the top one isn't (Firefox 3.0.1); does that mean this is a Firefox 3 regression in HTML/CSS support?

Firefox 1.0.8, 1.5.0.12 and 2.0.0.16 all show every item in blue. So the answer to my question in comment 5 is: yes, this is an amazing regression in HTML/CSS support in Firefox 3. :(

Looks like it was bug 357614 that switched all unknown attributes to be case-sensitive irrespective of content type. Sigh.

(In reply to comment #2) > HTML is case > insensitive, whereas XHTML is not. HTML tag names and attribute *names* are case insensitive. The case sensitivity of HTML attribute *values* varies depending on the attribute; see the "[CS]", "[CI]", etc., notations in the HTML4 spec.

(In reply to comment #8) > (In reply to comment #2) > > HTML is case > > insensitive, whereas XHTML is not. > > HTML tag names and attribute *names* are case insensitive. The case > sensitivity of HTML attribute *values* varies depending on the attribute; see > the "[CS]", "[CI]", etc., notations in the HTML4 spec. So in the dependent bug Gecko was made to treat unknown attributes in an HTML document case sensitively - can you elaborate on why that decision was made (part of the spec? IE-parity?), and/or if there is any way we can force a specific attribute to be treated case-insensitively? (AFAICT you're not getting bugmail right now, so I'm adding you to the CC list. Please excuse me if this is somehow a bad idea or against bugzilla etiquette, but I have no idea about how else to ask questions, short of adding comments to a different bug...)

Because I think the attributes added to HTML by new versions of the language are more likely to be case-sensitive (especially given the existence of XHTML, now), and because I thought that having a selector incorrectly match was a bigger problem than having it incorrectly not match. Then again, maybe I wasn't properly considering the case of style sheets written without knowledge of the document (although that is the rare case, in general).

I discussed this with Silver on #chatzilla, and he asks: "Would updating the motif to be all lower-case (and having ChatZilla do likewise in the HTML) be suitable?" This sounds like a solution to me

(In reply to comment #11) > I discussed this with Silver on #chatzilla, and he asks: > > "Would updating the motif to be all lower-case (and having ChatZilla do > likewise in the HTML) be suitable?" > > This sounds like a solution to me Yeah, that sounds like it should work. Looks like the css already is all-lowercase, so we'd have to fix the HTML only. Do we want to add another attribute, or change the existing one? Does any other code read this attribute and may expect it to be case-sensitive?

when will this be done?

(In reply to comment #13) > when will this be done? When the questions in comment #12 are answered, and someone has the time, energy, and will to do it. Also known as "when it's ready". In the meantime, you can trivially workaround by editing the CSS to use the capitalization of the given user's choice. Provided they don't change this too ridiculously too often, this should not be a problem.

This changes msg-user/msg-source from unicodeName to canonicalName. The context meny getUser calls are faster now as that's what they check first, but it has to call toUnicode manually if it didn't find the user object. No other code touched this, and it correctly produces "silver ME!" (so we don't break the ME! matching CSS).

Comment on attachment 364529 [details] [diff] [review] Use canonicalName in msg-user and msg-source >Index: static.js > <snip> >+ cx.nickname = toUnicode(cx.canonNick, cx.network); Please use cx.channel here if available. With that, r=me.

cx.channel would be wrong there, nicknames are always and only encoded with the network's charset.

Checked in --> FIXED.