XUL should be fully case sensitive

RESOLVED FIXED

Status

()

Core
XUL
RESOLVED FIXED
14 years ago
9 years ago

People

(Reporter: sicking, Assigned: sicking)

Tracking

({perf})

Trunk
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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.

Comment 3

14 years ago
I can't think of any code that doesn't already use lowercase either.
Attachment #135010 - Flags: review?(bryner)
Attachment #135010 - Flags: review?(bryner) → review+
Attachment #135010 - Flags: superreview?(jst)
Comment on attachment 135010 [details] [diff] [review]
Make it so

sr=jst
Attachment #135010 - Flags: superreview?(jst) → superreview+
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.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
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.

Updated

9 years ago
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: shrir → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.