Closed Bug 110555 Opened 18 years ago Closed 18 years ago

Wipe out the default userChrome.css and userContent.css

Categories

(SeaMonkey :: UI Design, defect, P3)

x86
Windows 2000
defect

Tracking

(Not tracked)

RESOLVED FIXED
mozilla0.9.7

People

(Reporter: dp, Assigned: dp)

References

Details

(Keywords: perf)

Attachments

(1 file)

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
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla0.9.7
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.
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.
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.
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+
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+
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
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.