456341 - Faces motifs case dependent since Firefox 3

Status: RESOLVED FIXED

(Other Applications :: ChatZilla, defect)

Description

[Jan Eri]

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.

Comment 1

[James Ross]

This is Firefox's fault.

Comment 2

[:Gijs (he/him)]

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

Comment 3

[[e-mail]]

Attachment: Test case

Each sample of text should of course be blue.

Comment 4

[[e-mail]]

Comment on attachment 339764 [details]
Test case

Oops, ticked the wrong box ;-)

Comment 5

[James Ross]

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

Comment 6

[James Ross]

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. :(

Comment 7

[James Ross]

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

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(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.

Comment 9

[:Gijs (he/him)]

(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...)

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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).

Comment 11

[Jan Eri]

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

Comment 12

[:Gijs (he/him)]

(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?

Comment 13

[Bjorn Olsen]

when will this be done?

Comment 14

[:Gijs (he/him)]

(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.

Comment 15

[James Ross]

Attachment: Use canonicalName in msg-user and msg-source

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 16

[:Gijs (he/him)]

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.

Comment 17

[James Ross]

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

Comment 18

[James Ross]

Checked in --> FIXED.