Closed Bug 817295 Opened 12 years ago Closed 10 years ago

chrome directory missing in fresh profiles (again)

Categories

(SeaMonkey :: Startup & Profiles, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
seamonkey2.30

People

(Reporter: InvisibleSmiley, Assigned: philip.chee)

References

()

Details

(Keywords: regression)

Attachments

(2 files, 1 obsolete file)

+++ This bug was initially created as a clone of Bug #728840 +++

Bug 728840 was fixed but the bug is back.

STR (only checked on Linux):
1. Start recent SM nightly with -P parameter so you get the profile selector
2. Create a new profile and start SM
3. Quit SM
4. Check the newly created profile directory (e.g. under ~/.mozilla/seamonkey)

Actual results:
No chrome directory
So it could be Bug 809798 - Don't use BOTH_MANIFESTS (for c-c).
Or less likely Part of Bug 781446 - Port bug 774032 (bonus only),  bug 763987, bug 742795 to comm-central. Port the bonus part of bug 774032 - Use @DEPTH@ and @relativesrcdir@ replacements in Makefile.in.
Or perhaps something completely different.
I was wondering what Firefox was doing right compared to us so I fired up Minefield/Nightly and discovered that Firefox has the same problem. Looking more closely it appears that the profile creation code can't find the files if they are packed into omni.jar. Move the relevant files from omni.jar to %SeaMonkey%/defaults/profile/ and the profile/chrome/ directory and associated files are once again created in new profiles.
(In reply to Philip Chee from comment #2)
> I was wondering what Firefox was doing right compared to us so I fired up
> Minefield/Nightly and discovered that Firefox has the same problem. Looking
> more closely it appears that the profile creation code can't find the files
> if they are packed into omni.jar. Move the relevant files from omni.jar to
> %SeaMonkey%/defaults/profile/ and the profile/chrome/ directory and
> associated files are once again created in new profiles.

>  NON_OMNIJAR_FILES = \
>  	defaults/messenger/mailViews.dat \
>  	defaults/profile/localstore.rdf \
>  	defaults/profile/panels.rdf \
> +	defaults/profile/bookmarks.html \
> +	defaults/profile/mimeTypes.rdf \
> +	defaults/profile/chrome/userChrome-example.css \
> +	defaults/profile/chrome/userContent-example.css \
>  	$(NULL)
Don't JAR the profile chrome files.

> -  defaults/profile/bookmarks.html
> -  defaults/profile/mimeTypes.rdf
> -  defaults/profile/chrome/
> -  defaults/profile/chrome/userChrome-example.css
> -  defaults/profile/chrome/userContent-example.css
If I don't remove these lines, make package or make installer complains and bails out. I don't know why really.
Assignee: nobody → philip.chee
Status: NEW → ASSIGNED
Attachment #8447681 - Flags: review?(bugzilla)
Attachment #8447681 - Flags: feedback?(jh)
Attachment #8447681 - Flags: feedback?(bugspam.Callek)
Comment on attachment 8447681 [details] [diff] [review]
Patch v1.0 Fix installer Makefile

I'll take whoever gets to review this first.
Attachment #8447681 - Flags: feedback?(bugspam.Callek) → review?(bugspam.Callek)
In /suite/locales/Makefile.in there is another NON_OMNIJAR_FILES usage:

NON_OMNIJAR_FILES = \
	defaults/messenger/mailViews.dat \
	defaults/profile/localstore.rdf \
	defaults/profile/panels.rdf \
	$(NULL)

Do I need to change this as well?
(In reply to Philip Chee from comment #5)
> In /suite/locales/Makefile.in there is another NON_OMNIJAR_FILES usage:
>[...]
> Do I need to change this as well?

I think so.
So wait, for me bookmarks.html gets copied to a new profile just fine?
Err, ok...I need a nightly build :) makes sense that it was wfm, after all omni.jar does not exist with local dev builds.
(In reply to Frank Wein [:mcsmurf] from comment #8)
> Err, ok...I need a nightly build :) makes sense that it was wfm, after all
> omni.jar does not exist with local dev builds.
You need to do |make package| (this creates the omni.ja file) and then install from that.
(Or make installer).

(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #6)
> (In reply to Philip Chee from comment #5)
> > In /suite/locales/Makefile.in there is another NON_OMNIJAR_FILES usage:
> >[...]
> > Do I need to change this as well?
> 
> I think so.

Changing this didn't affect my self build but I suspect it would be needed for L10n. Anyone want to try this patch out on a localized build?
OK this patch now allows the profile chrome directory and associated files to be created. Unfortunately there are one or two places in Gecko that are hardcoded to look for the bookmark.html in resource:///defaults/profile/bookmarks.html This resource resolves to omni.ja!/defaults/profile/ ... My patch moves defaults/profile/ to the non omni.ja location. How do I convince Make to leave a copy in omni.ja as well as outside?
Flags: needinfo?(bugzilla)
I think I've tracked this down to:
http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/profile/nsToolkitProfileService.cpp?mark=795-801#795

If someone can teach nsToolkitProfileService to use the nsIZipReader we can keep all the files in omni.ja.
I'm still not sure if Comment 2 is correct (although it looks like it). With a Firefox release build it creates a new profile with the default bookmarks from bookmarks.html just fine. So it does copy the files over? Or is just the chrome directory the problem?
So that's Comment 10 then (resource:///defaults/profile/bookmarks.html resolving to bookmarks.html inside omni.ja). So why not just leave bookmarks.html in omni.ja for now? Then we can resolve this one later.
Flags: needinfo?(bugzilla)
(In reply to Philip Chee from comment #9)
> (In reply to Robert Kaiser (:kairo@mozilla.com) from comment #6)
> > (In reply to Philip Chee from comment #5)
> > > In /suite/locales/Makefile.in there is another NON_OMNIJAR_FILES usage:
> > >[...]
> > > Do I need to change this as well?
> > 
> > I think so.
> 
> Changing this didn't affect my self build but I suspect it would be needed
> for L10n. Anyone want to try this patch out on a localized build?

IIRC, this is being used when doing L10n repacks, which are usually only done on our build machines (and somewhat nasty to test, actually).
Attached patch Patch v2.0 DonSplinter Review
>> for L10n. Anyone want to try this patch out on a localized build?
> 
> IIRC, this is being used when doing L10n repacks, which are usually only
> done on our build machines (and somewhat nasty to test, actually).

I guess that the only thing to do is to check this in and see if L10n blows up. :P
Attachment #8447681 - Attachment is obsolete: true
Attachment #8447681 - Flags: review?(bugzilla)
Attachment #8447681 - Flags: review?(bugspam.Callek)
Attachment #8447681 - Flags: feedback?(jh)
Attachment #8451662 - Flags: ui-review?(jh)
Attachment #8451662 - Flags: review?(bugzilla)
Attachment #8451662 - Flags: review?(bugspam.Callek)
Comment on attachment 8451662 [details] [diff] [review]
Patch v2.0 exclude bookmarks.html from NON_OMNIJAR_FILES

Works fine, does what it should!
Attachment #8451662 - Flags: ui-review?(jh)
Attachment #8451662 - Flags: review?(bugzilla)
Attachment #8451662 - Flags: review?(bugspam.Callek)
Attachment #8451662 - Flags: review+
Pushed to comm-central
http://hg.mozilla.org/comm-central/rev/d2a331abb0dc
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.30
You need to log in before you can comment on or make changes to this bug.