Wipe out the default userChrome.css and userContent.css

RESOLVED FIXED in mozilla0.9.7

Status

defect
P3
normal
RESOLVED FIXED
18 years ago
5 years ago

People

(Reporter: dp, Assigned: dp)

Tracking

({perf})

Trunk
mozilla0.9.7
x86
Windows 2000
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Assignee

Description

18 years ago
These two files seem to contain nothing. They get installed into the default
profile and get copied around into every profile. And we read these files on
startup.

chetu> pwd
/cygdrive/e/dp/opt.trunk/mozilla/profile/defaults/chrome
chetu> ls -l user*
-rw-r--r--    1 dp       None         1032 Sep 10 18:01 userChrome.css
-rw-r--r--    1 dp       None          503 Apr  4  2001 userContent.css

I am thinking of wiping them out and save two file reads on startup. Any harm ?
I can do it two ways:
- delete it from the defaults directory (my preference)
- delete code that copies it over to every profile when chrome/ directory is
created in nsChromeRegistry.cpp
Assignee

Updated

18 years ago
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla0.9.7
Assignee

Updated

18 years ago
Blocks: 7251
Keywords: perf
QA Contact: sairuh → jrgm
If we remove these files we should:

1)  re-silence the warning that always pops up when they're not there
2)  provide a clear accessibility document explaining how to create them and what
    should go into them (especially the namespace rule in userChrome.css)

The other thing to keep in mind is that even if we remove the files we still need 
to continue checking for their existence and reading them if they exist.

Comment 2

18 years ago
I would like to see solid measurements that indicate these files are causing a
perf penalty before removing them.  These files will still be checked for on
startup even if you remove them, so I'm not clear that there's any benefit to be
gained here.
Assignee

Comment 3

18 years ago
I renamed these files to userChrome-example.css and userContent-example.css, so
they still exist in the default profile directory and serve the same purpose
the older files did.

- Turned off warnings that showup when these files are missing. Didn't want to
add code to first check for existence of file as NS_OpenURI() in LoadSheet()
does that for us. Prefered the turning off css warning thing in debug code.

- Made chrome registry not return errors if these files didn't exist

If these files every existed in the default profile, they will get copies into
every new profile created. And these files, if they exist in user profiles,
will get loaded. All these are still intact.
Assignee

Comment 4

18 years ago
Comment on attachment 60225 [details] [diff] [review]
removes default userChrome.css and userContent.css

sr=hyatt (per showing this to him)
Attachment #60225 - Flags: superreview+
Assignee

Comment 5

18 years ago
dveditz - Could you review this patch. I checked the packager files and they
didn't list these files directly. Hence didn't have to modify them.
Comment on attachment 60225 [details] [diff] [review]
removes default userChrome.css and userContent.css

r=dveditz

We can change the install scripts if you want to delete the existing files from
the default location (so new profiles won't get them), but then we have to
worry about folks who have customized their setups so I'd recommend against
doing that.
Attachment #60225 - Flags: review+
Assignee

Comment 7

18 years ago
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED

Comment 8

18 years ago
After this went in, Bloat numbers dropped by 500k bytes; that's a lot. Can we
account for that 500k? Perhaps it points to some in-efficiencies.?
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.