Closed
Bug 817295
Opened 12 years ago
Closed 10 years ago
chrome directory missing in fresh profiles (again)
Categories
(SeaMonkey :: Startup & Profiles, defect)
SeaMonkey
Startup & Profiles
Tracking
(Not tracked)
RESOLVED
FIXED
seamonkey2.30
People
(Reporter: InvisibleSmiley, Assigned: philip.chee)
References
()
Details
(Keywords: regression)
Attachments
(2 files, 1 obsolete file)
2.38 KB,
patch
|
Details | Diff | Splinter Review | |
2.38 KB,
patch
|
mcsmurf
:
review+
|
Details | Diff | Splinter Review |
+++ 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
Assignee | ||
Comment 1•11 years ago
|
||
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.
Assignee | ||
Comment 2•10 years ago
|
||
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.
Assignee | ||
Comment 3•10 years ago
|
||
(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)
Assignee | ||
Comment 4•10 years ago
|
||
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)
Assignee | ||
Comment 5•10 years ago
|
||
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?
Comment 6•10 years ago
|
||
(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.
Comment 7•10 years ago
|
||
So wait, for me bookmarks.html gets copied to a new profile just fine?
Comment 8•10 years ago
|
||
Err, ok...I need a nightly build :) makes sense that it was wfm, after all omni.jar does not exist with local dev builds.
Assignee | ||
Comment 9•10 years ago
|
||
(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?
Assignee | ||
Comment 10•10 years ago
|
||
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)
Assignee | ||
Comment 11•10 years ago
|
||
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.
Assignee | ||
Comment 12•10 years ago
|
||
> http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/profile/ > nsToolkitProfileService.cpp?mark=795-801#795 Perma-link: http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/profile/nsToolkitProfileService.cpp?rev=461ad7d4f1ef&mark=795-801#794
Assignee | ||
Comment 13•10 years ago
|
||
> http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/profile/ > nsToolkitProfileService.cpp?mark=795-801#795 Perma-link: http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/profile/nsToolkitProfileService.cpp?rev=461ad7d4f1ef&mark=795-801#794
Comment 14•10 years ago
|
||
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?
Comment 15•10 years ago
|
||
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)
Comment 16•10 years ago
|
||
(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).
Assignee | ||
Comment 17•10 years ago
|
||
Assignee | ||
Comment 18•10 years ago
|
||
>> 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 19•10 years ago
|
||
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+
Assignee | ||
Comment 20•10 years ago
|
||
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.
Description
•