Need to remove debug and test files from the res directory




18 years ago
9 years ago


(Reporter: Simon Fraser, Unassigned)



Firefox Tracking Flags

(Not tracked)




18 years ago
The /res directory in the application directory should be eliminated before 
shipping; any required files in there should be moved into /chrome.

Comment 1

18 years ago
cc morse: some wallet/singsong stuff goes into res.

So are there any files that cannot go into chrome:/? Do we actually need a place 
to put non-UI files? If so, I suggest 'resources'. On Mac, this should go into 
the Essential Files folder.

Comment 2

18 years ago
Does this mean that a hard-coded URI like "resource:/res/quirk.css" will have to 

Comment 3

18 years ago
Yes. You should certainly be using a chrome: URL for things like that.

Comment 4

18 years ago
Per ben..
"As part of the skinnability drive for nsbeta2, and for platform
cleanliness for mozilla, many of the resource files under
mozilla/xpfe/global/resources are being refactored or moved int

POutting on [nsbeta2+] radar.
Keywords: nsbeta2
Whiteboard: [nsbeta2+]

Comment 5

18 years ago
Sorry for the spam.  New QA Contact for Browser General.  Thanks for your help
Joseph (good luck with the new job) and welcome aboard Doron Rosenberg
QA Contact: jelwell → doronr

Comment 6

18 years ago
Wallet tables are now out of the res directory.  Simon, res never had any 
"singsong" stuff, whatever that is.

Comment 7

18 years ago
I meant single signon, of course (as implemented in the memorable singsign.cpp) 

Comment 8

18 years ago
Res never had any single signon stuff in it.

Comment 9

18 years ago
David: This is part of the "repackage into jar files" bug. As you see our build 
system copying things to the dist/bin/res directory, you should investigate 
what should be the appropriate jar file for these things (e.g. core.jar), and 
make you jar packaging put them in the new place. You'll also have to find and 
change any resource: urls to be chrome: urls that point to the new file's 
Assignee: warren → dprice

Comment 10

18 years ago
David: See my last comment on this bug.

Comment 11

18 years ago
repackage resources into jar files bug is

Comment 12

18 years ago
Per today's PDT, moving from [nsbeta2+] to [nsbeta2-]
Whiteboard: [nsbeta2+] → [nsbeta2-]

Comment 13

18 years ago
doh, wrong defect.  Dave needs sleep badly.

Comment 14

18 years ago
nominate for beta3. If it doesn't go away by beta 3 it never will, and that would 
be bad. Note that we also now have another dir, psmdata, polluting the 
application directory. These must be cleaned up!
Keywords: nsbeta3

Comment 15

18 years ago
I thought we nsbeta3+'d this a long time ago.
Whiteboard: [nsbeta2-] → [nsbeta3+][nsbeta2-]

Comment 16

18 years ago
Unfortunately, this is a P3 priority and PDT was looking at P1-P2 bugs to mark
nsbeta3++ or not.

If this really needs to get into nsbeta3, I'd suggest emailing PDT.   Thanks!

Comment 17

18 years ago
we need this for RTM.
Keywords: rtm

Comment 18

18 years ago
Are we just trying to get rid of obsolete files?  I don't think we need to get 
rid of the directory itself.  The HTML implementation files should not be moved 
into chrome.  They aren't chrome, they have nothing to do with xul, and they 
don't belong in a jar (since I could see embedding folks cutting out the JAR 
protocol for space).

Comment 19

18 years ago
Then we need a better place for non-chrome resource files; there is some stuff in 
res, and in psmdata.

I object to having a folder called "res" in the application directory because Mac 
users will laugh and point at it, then throw it in the trash. It needs to be 
"Resources" or something. Ideally, on Mac, it would move under Essential Files.

Comment 20

18 years ago
I don't care if we move the core HTML files into some other directory with a 
better name.  I'm just making sure we don't throw a bunch of files into chrome 
that we shouldn't.  :)

Comment 21

18 years ago
Arguably, "res" (or "resources") is a generalization of "chrome". Maybe we 
should put the chrome jars under res (although actually, I think this is 
unimportant). Nonetheless, the things in res (including psm stuff) should get 
packaged into some jar. Right now, necko is in the comm.jar file. I don't see 
why other subsystems should be different.

Comment 22

18 years ago
Not holding PR3 for this. Marking nsbeta3-
Whiteboard: [nsbeta3+][nsbeta2-] → [nsbeta3-][nsbeta2-]

Comment 23

18 years ago
*** Bug 54445 has been marked as a duplicate of this bug. ***
OS: Mac System 8.5 → All


18 years ago
Blocks: 32486

Comment 24

18 years ago
adjust summary. dprice, any progress on this?
Summary: res directory needs to go away → Need to remove debug and test files from the res directory

Comment 25

18 years ago
I'm working on finding good homes for some of the files.  The .properties files
concern me at the moment because I think they belong in a locale jar.  If they
are res, they aren't being localized.
Also there are considerably more files installed in the res directory for
mozilla than are installed for netscape.
When you say "installed... for mozilla" do you mean you actually used the 
mozilla installer, or did you just unpack the nightly zipfile? The zipfile 
contains whatever the build happens to produce including test files and old 
cruft. From what I can see the res directory in a Commercial installed build 
has exactly what's in a mozilla /installed/ build plus two more files.

Comment 27

18 years ago
I disagree with this bug.  We should not be moving required files into the
chrome directory or worse inside a jar file.  bits that are required for basic
html layout should not require chrome (and RDF).  We have customers that was
smaller footprint.  we want to be able to strip out chrome and RDF if the
customer wants just html layout without the hassle of moving files from chrome
into res.

Comment 28

18 years ago
I agree with Doug.  Basic files required by HTML (that doesn't use chrome to 
perform localization) should be loose in their own directory (as they are now). 
I was relying on this as well, since I need to move some more files out of 
chrome that don't belong there.

Comment 29

18 years ago
I have to disagree with you guys. My vision is that every Component consists of 
a dll and a jar file for its resources. The contents of these jar files may get 
combined into an uber-jar for a particular shipping product (like we do with 
comm.jar now), but there shouldn't be random odds and ends scattered around the 
bin directory.

Are you worried about the need to include the jar protocol code and zip 
library? I think that's pretty minimal. And access time is better than flat 
files, so that can't be the issue.

Comment 30

18 years ago
warren, you sounded like the boss in office space! ;)

"Ummm, yeeeeaaah.  I think I'm going to have to go ahead and *disagree* with you 

Comment 31

18 years ago
I like this conceptually.  The problem that I have is that if you drop something
into the chrome directory structure, in terms of footprint, it is very heavy.
In order to use chrome:// you need around 700k of stuff :

-rwx------    1 dougt    dougt        107k Oct 17 08:41
-rwx------    1 dougt    dougt         44k Oct 17 08:41
-rwx------    1 dougt    dougt        552k Oct 17 08:41

(numbers from a netscape 6 optimized build from a few days ago)

Maybe we should just rewrite chrome so that it does not depend of RDF (David, is
this absurd?), but until then adding this much bloat for something the file
system provides (file access) is not a good thing for embedding.


Comment 32

18 years ago
Is this rdf number that big because it still contains xul elements, etc.? If so, 
we're going to take that out, right? I don't know why the chrome registry is so 

What about the zlib dll? I assume you still need that for xpt files, right?

So what does the boss from office space sound like?

Comment 33

18 years ago
We're cutting chrome for embedding.  We don't need it at all unless we're 
using XUL.  Don't stress over it.

Comment 34

18 years ago
yes, that rdf number includes XUL.  Waterson or Hyatt would know the rough
estimates of what percent is xul in that rdf xul.  I remember something like
75/25 but do not remember which is which right now.

zlib, at least on my system is part of the dist (installed in /lib or /usr/lib).
 I am not sure if mobile linux includes zlib or not, but in either case it is
quite small. I think mozilla's zlib is something like 35 or so k.

So, I guess what I am arguing for is that we wait until we can minimize the
footprint needed to support chrome urls before adding more required files there.

Comment 35

18 years ago
Yeah, but what about the other core files that are currently in jars? Necko and 
xpcom string bundles, for instance.

Comment 36

18 years ago
have they already moved into chrome/jar paths?

Comment 37

18 years ago
rtm-, this does not appear to be an rtm bug.
Whiteboard: [nsbeta3-][nsbeta2-] → [nsbeta3-][nsbeta2-][rtm-]

Comment 38

17 years ago
I think if there is some idea that we could get 
a performance or other big gain out of doing this
if might sound worthwhile.  until we see  the big
advantage moving this to the back burner.
Target Milestone: --- → Future
the big advantage is that we no longer look like idiots for shipping all these 
files. maybe that's no big deal on win32, but it is on mac.
Keywords: nsbeta2, nsbeta3, rtm
Whiteboard: [nsbeta3-][nsbeta2-][rtm-]

Comment 40

15 years ago
We're still shipping 500k of crap in res/samples (on Mac at least). Why?
Assignee: dprice → seawood
Component: Browser-General → Build Config
Priority: P3 → P2
QA Contact: doron → granrose
Target Milestone: Future → ---

Comment 41

15 years ago
I think we can remove all of res/samples, res/rdf, and res/throbber.

Comment 42

15 years ago
I think the right thing to do here is to make Mac OS X run the stuff in
xpinstall/packager. We'd probably want to use to copy from
dist/Mozilla{Debug}.app to the target, using a new packages-macho.

Even if we do this, we'll still get res/samples etc, which we don't seem to
strip out, even for milestone builds. But at least we can fix that XP then.
I fail to see why this is considered a Build Config issue.  If the files under
res/ are unneeded, then tell the component owners to stop dumping their crap
there by default.  Making OSX use packages-mac is a separate issue IMO and
doesn't address the actual problem here.  Tarball builds will still have this cruft.
Assignee: seawood → sfraser

Comment 44

15 years ago
Bug 203106 filed on getting Mac OS X to do packaging stuff. Reassiging this bug
to layout, who own most of the res/samples and res/throbber crap.
Assignee: sfraser → other
Component: Build Config → Layout
QA Contact: granrose → ian


15 years ago
Target Milestone: --- → Future

Comment 45

13 years ago
There is still a lot of unneeded stuff in /res, and some of the 'needed' stuff
can problably moved to chrome://...
Assignee: layout → nobody
QA Contact: ian → layout
You need to log in before you can comment on or make changes to this bug.