Last Comment Bug 223012 - XUL should be fully case sensitive
: XUL should be fully case sensitive
Status: RESOLVED FIXED
: perf
Product: Core
Classification: Components
Component: XUL (show other bugs)
: Trunk
: x86 Windows 2000
: -- normal (vote)
: ---
Assigned To: Jonas Sicking (:sicking) No longer reading bugmail consistently
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2003-10-20 14:40 PDT by Jonas Sicking (:sicking) No longer reading bugmail consistently
Modified: 2008-07-31 03:14 PDT (History)
6 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Make it so (30.85 KB, patch)
2003-11-07 13:31 PST, Jonas Sicking (:sicking) No longer reading bugmail consistently
bryner: review+
jst: superreview+
Details | Diff | Splinter Review

Description Jonas Sicking (:sicking) No longer reading bugmail consistently 2003-10-20 14:40:17 PDT
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 2003-11-07 13:31:24 PST
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.
Comment 2 Boris Zbarsky [:bz] 2003-11-07 13:48:42 PST
If I recall correctly, accesskeys are supposed to do a case-sensitive match
first; if that fails, try case-insensitive.
Comment 3 neil@parkwaycc.co.uk 2003-11-07 13:52:26 PST
I can't think of any code that doesn't already use lowercase either.
Comment 4 Johnny Stenback (:jst, jst@mozilla.com) 2003-11-17 17:01:53 PST
Comment on attachment 135010 [details] [diff] [review]
Make it so

sr=jst
Comment 5 Boris Zbarsky [:bz] 2003-11-18 20:57:19 PST
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 2003-11-19 09:08:05 PST
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 [:bz] 2003-11-19 09:23:13 PST
Maybe we should change that?
Comment 8 Jonas Sicking (:sicking) No longer reading bugmail consistently 2003-11-19 09:32:25 PST
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.

Note You need to log in before you can comment on or make changes to this bug.