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
Created attachment 135010 [details] [diff] [review] 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.
If I recall correctly, accesskeys are supposed to do a case-sensitive match first; if that fails, try case-insensitive.
I can't think of any code that doesn't already use lowercase either.
14 years ago
14 years ago
Comment on attachment 135010 [details] [diff] [review] Make it so sr=jst
Hmm... the use of NS_LITERAL_STRING there had a fairly hefty codesize effect... Any idea why?
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.
Maybe we should change that?
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.