Closed Bug 107694 Opened 23 years ago Closed 23 years ago

Netscape and Mozilla shouldn't use same profile dir.

Categories

(Derivatives Graveyard :: Netscape 6, defect)

Product:
Derivatives Graveyard
Component:
Netscape 6
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED MOVED

People

(Reporter: h-dot, Assigned: lchiang)

References

Details

(Keywords: dataloss)

From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) BuildID: Netscape and Mozilla both use C:\documents and settings\<user>\application data\mozilla\ for storing profile data. Both netscape and mozilla writes to the file registry.dat, it keeps me from running mozilla and netscape at the same time with different skins for example. Reproducible: Didn't try Steps to Reproduce: Expected Results: Netscape should use Netscape folder instead of mozilla folder in Application Data
i run mozilla and ns6 concurrently on w98. I can pick skins for each independently. the only thing i shouldn't do is select the same profile. steps: 1. mozilla -profilemanager 2. create a second profile 3. netscp6 4. select some profile other than the one mozilla is using. 5. randomly change theme for one of the apps 6. quit that app 7. run that app 8. select the profile that was previously active in that app
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Netscape shouldn't use mozilla's default profile. They shouldn't share profile's at all since they're not from the same branch 0.9.4(ns) 0.9.5+(moz), different chromes and probably more differneces. At least netscape shouldn't _default_ to mozilla's profile, instead it should give me an option to create a new profile or, on my request, use the same profile for both. This should work both ways, so mozilla doesn't default to ns's profile either.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
branches are an interesting point. iirc Mozilla is supposed to warn if the chrome/localizations don't match, so there shouldn't be a problem. The big problem is that afaik there's no space to stick such a preference. We could probably allocate space in the profile registry for each conceivable application to say 'i <application> warned the user', but i don't think we really want to do that. Alternatively, if there's only one profile, we could ask the profile what applications have been authorized to use it, if we aren't among them, we could warn -- that would probably be implementable. The problem here is that for each profile which a user wanted to share among applications (and i have: Netscape6, Beonex, Komodo, Mozilla, WinEmbed, MFCEmbed) they'd be prompted about this, i'd imagine that would be rather annoying. Anyways, the preceding would be possible concerns for the backend to this bug. I'm going to send this to the FE people to consider.
Assignee: asa → ben
Component: Browser-General → Profile Manager FrontEnd
QA Contact: doronr → ktrina
Summary: Netscape and mozilla sholudn't use same profile dir. → Netscape and mozilla shouldn't use same profile dir.
On the face of it this should be INVALID as a Mozilla bug and should be directed to Netscape via their feedback mechanisms. Frankly I doubt this will change. At a marketing level there's not going to be much interest because an insignificant fraction of Netscape's customer base also use Mozilla, and at the grass-roots level all of the Netscape programmers who would do the work find it very convenient to share profiles between Mozilla and Netscape and know how to avoid the pitfalls.
I'll report this to netscape, for the correctness of it netscape should use it's own app. settings directory/files. But something that moz needs is an option to tell different insatallations(branches/milestones/nightlys) to default to a profile of my choice. Ex. I use moz milestones as my main browser/mail/news client. Whenever I start the milestone I wan't it to always pick my milestone profile without asking. I also download nighlies every day to test new features and check if bug's have been fixed. Now these should display the profile manager so I can select/create another profile to use for testing.
I would also say this should be invalid. Rather than masking problems by having separate profile registries and profiles between products (NS and mozilla) and milestones, the data in files within a profile dir should be compatible between products and milestones. Then, this wouldn't be an issue. So, I think this is invalid and a better bug would be: Netscape and mozilla should be able to *successfully* use the same profile dir.
Conrad Carlen: >So, I think this is invalid and a better bug would be: Netscape and mozilla >should be able to *successfully* use the same profile dir. 1. Problem : You can't run 2 instances at once (there are already bugs in bugzilla about this) 2. Netscape custom skins : You can use this skins because they will not working in Mozilla because too many changed in the Theme Syntax. This should be better with Mozilla 1.0 (XUL Sntax freeze) 3. Lang-Packs: Mozilla should be able to detect an old lang-pack in the profile and use the standard en-us pack. 4. Homepage override: If you run Mozilla and then Netscape with the same profile you will forced to load the start page every time (Mozilla.org/start, Netscape.com/???)
another possible problem is in bug 108849 (cache related)
See bug 119941 for an example of how a profile shared by Netscape and Mozilla became corrupted. The file _CACHE_001_ was the central issue there. I think we should confirm this one. There's just too much weirdness that can happen. It's possible that a Netscape 6.0 build could try to use the same profile as a Mozilla 0.9.8 build. Bad things are likely to happen. If it turns out that we can resolve those potential problems, then we should retire this bug as invalid. Until then, though, let's mark it new.
Summary: Netscape and mozilla shouldn't use same profile dir. → Netscape and Mozilla shouldn't use same profile dir.
*** Bug 128410 has been marked as a duplicate of this bug. ***
*** Bug 128411 has been marked as a duplicate of this bug. ***
I think perhaps people are misjudging both the importance of this problem and simplicity of the solution. Mozilla & Netscape sharing the same (profile root) Application Data folder ('mozilla') is problematic, netscape is always going to be behind the latest mozilla and big changes in mozilla settings can break netscape (or make it pretty wacky). mozilla based products should have their own prefs as they will all be built from different distributions, therefore mozilla should keep the root folder 'mozilla' and netscape should use 'ns_mozilla' or equivalent, everyone's happy. Or make the root profile folder name configureable so that just mozilla users have to worry about it and can happily co-exist with whatever the latest Netscape release is.
Blocks: 128410, 128411
I agree wholeheartedly with Cristopher. "Netscape" and "Mozilla" should do the trick. That should go for any other application that shares profiles currently (except embedding). Just because it isn't a problem now doesn't mean it won't be an embarrassment in the future when there are more users. Besides, this is not something that developers should have to deal with either, and its not fair to us to say marketing doesn't care when we put our free time into the project. Simple fix: NS6.5 installation, move the profile directory to "Netscape" and change the settings. Besides, you will see the two bugs that I just filed, bug 128410 and bug 128411 can be fixed by this, and currently they are a problem even if you don't choose the same profile.
*** Bug 123995 has been marked as a duplicate of this bug. ***
*** Bug 133083 has been marked as a duplicate of this bug. ***
Confirming as an enhancement request. The Mozilla 1.0 RC1 release notes say that you should not use the same profile with Mozilla and Netscape. Thus, the two should not share the same profile directories or the same registry.dat files. All/all. Nominating for nsbeta1.
Blocks: profile-corrupt
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: nsbeta1
OS: Windows 2000 → All
Hardware: PC → All
Nav triage team: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
renominating based on recent feedback from mozilla users (who number in the hundreds of thousands now), and industry press; and then there are all the defects that this causes...
Keywords: nsbeta1- → nsbeta1
Shouldn't Netscape fix this ? use application Data/.../Netscape/ instead of application Data/.../Mozilla/
why is this valid in bugzilla? Mozilla correctly uses a "Mozilla" directory. Netscape should use Netscape, but that's a netscape change and should therefore be in bugscape, not bugzilla
Biesi: That depends on how hard it is to change the profile directory. If its hard -coded all over the Mozilla source, then it might have to be moved to one central location. Otherwise, if its just a simple change in some data file - it is something that needs to be done on the private Netscape code - which will also mean modifying the Netscape installer to move the profile when upgrading. In that case, this bug (or a clone thereof) does belong in Bugscape.
Can somebody put this in Bugscape? Is this already a bug over there? Since NS7 RC1, I've read how many people (as well as myself) have had problems with both Netscape and Moz installed at the same time. In fact, even the reviewer(s) that did the CNET review of NS7 print that there were problems having both installed at the same time: "Unfortunately, when we attempted to install Netscape and Mozilla on the same PC, we were plagued by problems". I know to get them both to work right I need to create profiles in different places, but I shouldn't have to.
>Biesi: That depends on how hard it is to change the profile directory. --with-user-appdir=.netscape trivial. beonex does it too.
critical/dataloss. --> Derivatives, Netscape 6.
Assignee: ben → lchiang
Severity: enhancement → critical
Component: Profile Manager FrontEnd → Netscape 6
Keywords: dataloss
Product: Browser → Derivatives
QA Contact: ktrina → lchiang
Version: other → unspecified
Well, once I move this bug into bugscape, the majority of the folks on the cc: list won't be able to view the actual bug report anymore. It seems to me that the problems reported were that there would be blank IM sidebar tabs in Mozilla and that a webmail account set up through Netscape would not be able to be used in Mozilla. I will move this to bugscape for consideration.
Bug moved to http://bugscape.netscape.com/. If the move succeeded, lchiang@netscape.com will receive a mail containing the number of the new bug in the other database. If all went well, please mark this bug verified, and paste in a link to the new bug. Otherwise, reopen this bug.
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → MOVED
verified that bug has been moved.
Status: RESOLVED → VERIFIED
lchiang: I don't think this is a Netscape specific problem. As trudelle pointed out recently in a post to .general, Mozilla should have a better extensibility story when it comes to profiles, especially given that there are multiple distributors of Mozilla-based browser products (eg netscape, galeon, mozilla, k-meleon, skipstone, chimera, etc). Can we move this discussion back to bugzilla by opening a new bug?
Dan - I don't want to get involved on where this bug resides and move things back and forth. For the short term, the contents of this bug report have been replicated to Netscape's internal bug tracking so Netscape can make a decision on what it wants for Netscape 7.0. There are two options to continuing the profile extensibility discussion - reopen this bug or open a new bug which is more general for all distributors of the Mozilla code. Please take the course of which one you feel is more applicable. Thanks!
Dan, the location of the directory containing the registry and profiles is very extensible. An embedding app simply installs its own directory sevrice provider and it can customize that location and many others. All of our embedding sample apps do this, as well as galeon and probably others. To say that this is not extensible isn't quite right. On the other hand, adding your own directory service provider requires some work (creating and registering an object) Certain apps probably just want to just set a build var and compile without adding any code. For that, see bug 58237. I think that should be pursued.
Actually, my post just pointed out that the bug might go in bugzilla, as a fix need not be entirely Netscape commercial, and the debate should certainly not shut out many of the people affected. BTW, how about a pointer to the Bugscape number here?
I reported a bug on losing the Personal Toolbar personalized entries in Moz when you install Netscape Navigator a long time ago. I've been reading so many comments on this bug recently that I thought I'd throw in my 2 cents' worth. Sorry for stating the obvious, but I guess the problem stems from Mozilla using Navigator's code base. I imagine that the profile dir is hard-coded into each component of Mozilla as well as Navigator, so it would be time-consuming to edit the code and test. I imagine that there are no easy fixes with this. Unfortunately for Mozilla, if my opinion counts for anything, I feel that Navigator as a product precedes it, and the onus lies upon Mozilla to correct the inherited problem. However, in my opinion, if there were some way of solving this in a quick and dirty but acceptable way, that would be great. Like arbitrarily setting up a profile that Mozilla components would use, if necessary cooperating with Netscape to add a new field that points to the Mozilla profile. I really don't know how Mozilla and Navigator are organized so I can't really offer an intelligent suggestion.
>I imagine that the profile dir is hard-coded into each >component of Mozilla as well as Navigator, so it would be time-consuming to edit >the code and test. as I said before, this is not correct, see comment 23
Sorry, the bug num I gave in comment 30 was wrong. The actual bug num is bug 58327. That bug allows for improvement over just using --with-user-appdir=foo. The problem with --with-user-appdir=foo is it doesn't work on all platforms. With some more work on bug 58327, something could be set in the perl build scripts on Mac and work on *all* platforms - the only kind of solution we should be interested in ;-) As far as being mozilla vs NS bug, all of the work to allow this configurability is within the mozilla tree. Once we have that build-time configurability and, if NS wants to use it, that's a bugscape bug. CC'ing ben since he owns the bug I mention. Discussion of what needs to be done in the mozilla tree should move there.
For trudelle's comment: http://bugscape.netscape.com/show_bug.cgi?id=16017
Another problem of different apps sahring a profile is that the defaults prefs differ, and the user pref will be reset, if one of the default prefs matches. See bug 58326. As for implementation, apart from bug 58327, there's the problem of migration. Probably easy to implement (just copy), but still needs to be done. Is there a bug on it? It wouldn't be Netscape-specific, because Beonex uses its own profile base dir, too, and migration from Netscape 6 / Mozilla (not just 4.x) might be nice. Same for Netscape 6 -> Mozilla.
*** Bug 54456 has been marked as a duplicate of this bug. ***
*** Bug 149738 has been marked as a duplicate of this bug. ***
*** Bug 139711 has been marked as a duplicate of this bug. ***
Blocks: clodern
*** Bug 188703 has been marked as a duplicate of this bug. ***
*** Bug 206581 has been marked as a duplicate of this bug. ***
*** Bug 207386 has been marked as a duplicate of this bug. ***
*** Bug 211172 has been marked as a duplicate of this bug. ***
*** Bug 241286 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.