Closed Bug 41567 Opened 24 years ago Closed 6 years ago

Need to remove debug and test files from the res directory

Categories

(Core :: Layout, defect, P2)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
RESOLVED INCOMPLETE
Milestone:
Future

People

(Reporter: sfraser_bugs, Unassigned)

References

Details

The /res directory in the application directory should be eliminated before shipping; any required files in there should be moved into /chrome.
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.
Does this mean that a hard-coded URI like "resource:/res/quirk.css" will have to change?
Yes. You should certainly be using a chrome: URL for things like that.
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 xpfe/communicator." POutting on [nsbeta2+] radar.
Keywords: nsbeta2
Whiteboard: [nsbeta2+]
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
Wallet tables are now out of the res directory. Simon, res never had any "singsong" stuff, whatever that is.
I meant single signon, of course (as implemented in the memorable singsign.cpp) ;)
Res never had any single signon stuff in it.
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 location.
Assignee: warren → dprice
David: See my last comment on this bug.
FYI... repackage resources into jar files bug is http://bugzilla.mozilla.org/show_bug.cgi?id=18433
Per today's PDT, moving from [nsbeta2+] to [nsbeta2-]
Whiteboard: [nsbeta2+] → [nsbeta2-]
doh, wrong defect. Dave needs sleep badly.
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
I thought we nsbeta3+'d this a long time ago.
Whiteboard: [nsbeta2-] → [nsbeta3+][nsbeta2-]
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!
we need this for RTM.
Keywords: rtm
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).
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.
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. :)
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.
Not holding PR3 for this. Marking nsbeta3-
Whiteboard: [nsbeta3+][nsbeta2-] → [nsbeta3-][nsbeta2-]
*** Bug 54445 has been marked as a duplicate of this bug. ***
OS: Mac System 8.5 → All
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
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.
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.
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.
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.
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 there."
warren, 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 libchrome.so -rwx------ 1 dougt dougt 44k Oct 17 08:41 libjar50.so -rwx------ 1 dougt dougt 552k Oct 17 08:41 librdf.so (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. --doug
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 big. 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?
We're cutting chrome for embedding. We don't need it at all unless we're using XUL. Don't stress over it.
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.
Yeah, but what about the other core files that are currently in jars? Necko and xpcom string bundles, for instance.
have they already moved into chrome/jar paths?
rtm-, this does not appear to be an rtm bug.
Whiteboard: [nsbeta3-][nsbeta2-] → [nsbeta3-][nsbeta2-][rtm-]
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-]
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 → ---
I think we can remove all of res/samples, res/rdf, and res/throbber.
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 pkgcp.pl 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
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
Target Milestone: --- → Future
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
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.