223012 - XUL should be fully case sensitive

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

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

Right now XUL-attributes are mostly interpreted in a case-sensitive manner.
Specifically all the parts of XUL that are implemented using CSS+XBL is
case-sensitive. However there are a few attributes that are implemented using
C++ code that does case insensitive stringcompares.

This is bad first of all for inconsistency-reasons, especially since XUL is
based on XML that is inherently case sensitive. Second, caseinsensitive
stringcompares are a lot more expensive then their casesensitive counterparts.

See also bug 221026

Comment 1

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

Attachment: Make it so

I searched all of content/xul and layout/xul for "IgnoreCase" and "Insensitive"
and made all references that refers to attribute-names and attribute-values
case sensitive. The only exception is accesskeys that i'm not sure if they
might need to be case sensitive.

I searched the tree using lxr textsearch for most of the attributes and didn't
find a single case where we used uppercased attribute-values. I've also been
running with this build for a few days without any problems, including running
mailnews and chatzilla.

Comment 2

[Boris Zbarsky [:bzbarsky]]

If I recall correctly, accesskeys are supposed to do a case-sensitive match
first; if that fails, try case-insensitive.

Comment 3

[[e-mail]]

I can't think of any code that doesn't already use lowercase either.

Comment 4

[Johnny Stenback (:jst)]

Comment on attachment 135010 [details] [diff] [review]
Make it so

sr=jst

Comment 5

[Boris Zbarsky [:bzbarsky]]

Hmm... the use of NS_LITERAL_STRING there had a fairly hefty codesize effect...
Any idea why?

Comment 6

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

It's most likly not the use of NS_LITERAL_STRING that caused the increase, but
the use of Equals rather then EqualsIgnoreCase. The former inlines a lot more
then the latter does.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Maybe we should change that?

Comment 8

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

Definitly. We had a discussion on #mozilla last night and basically we need to
look over strings and determain what should be inlined and what should not.
There are fixes that needs to be done in both directions.