Can't run two versions of app w/out trashing registry

RESOLVED FIXED in M8

Status

()

P3
normal
RESOLVED FIXED
20 years ago
10 years ago

People

(Reporter: mikepinkerton, Assigned: dp)

Tracking

Trunk
All
Mac System 8.5
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

20 years ago
I have two builds of the app from the same day with some UI tweaks in each. They
are located on different drives. However, I can't run one and then the other
without trashing the "Mozilla Registry" file first.

What I get when I do this is a slew of asserts at startup and then the browser
comes up with no chrome and an http error 500. If I pitch the registry file, all
is well. It seems the registry is storing a little too much information there,
and doesn't know how to "re init" itself when another instance of the app comes
along.

I'm sure this will bite end users and is something that we need to fix at some
point.

Comment 1

20 years ago
This would be because the registry is storing full paths, right dp?

Comment 2

20 years ago
pinkerton, Mac only bug?
(Reporter)

Comment 3

20 years ago
probably mac only. my other two boxes are dead right now.
(Assignee)

Updated

20 years ago
Status: NEW → ASSIGNED
Target Milestone: M8
(Assignee)

Comment 4

20 years ago
Yes this is expected as the mozilla registry is shared by both the builds.

Full pathnames wont cause this.

The solution is to have application specific registry as in the two build should
use different registry files. But that is wierd. Got to think more.

Comment 5

20 years ago
If running two copies is a required feature (and I doubt that it is, no previous
version allowed this, either) then we'll need to design how to fix this.

However, to me, this bug looks "invalid", and I won't yell too much if dp marks
it so.
(Reporter)

Comment 6

20 years ago
I don't mean "at the same time" I mean "two copies ever". Imagine if one version
gets corrupted somehow (some kid deletes the toolbar gifs) and I d/l another one.
It won't work because the registry is coded to the last one.

That's not a good user experience.

Comment 7

20 years ago
Oops. Then I withdraw my inappropriate remarks (leaving only the appropriate
ones, like "and" and "the".  :-)

Comment 8

20 years ago
If pink had said "at the same time", I'm sure even worse things would happen to
the registry. We need the stupid "We're too lame to allow you to run two copies
at the same time" check that 4.x has.
(Assignee)

Comment 9

20 years ago
I do understand that "not at the same time" was what pink meant.

Even that needs a lot of thought. Issues would be:

- is reregistration of components every time you switch builds ok
- should the realaudio component that you installed work with both builds
- how to reclaim registry space once a build is deleted

Comment 10

20 years ago
dp, what if the registry was stored locally to each copy of the application. That
might kill two birds with one stone:
1. It would fix this bug.
2. It would allow you to store only relative paths to components, rather than
   full paths. That is somewhat more palatable to us Mac fiends.
We have a similar problem on Unix, especially for developers who build on
multiple platforms. The registry in their ~/.mozilla/registry file will reflect
only one of them and cause screwups when they switch back and forth.

Putting the registry with the executable would appear to solve this, but on
Unix not really because the typical user cannot write to where the
executable lives.

A solution that parallels the "version registry" solution is to key a "mozilla
installation" by directory and at XPCOM startup figure out which of multiple
mozillas is the right one and then do everything relative to that key for the
duration of the session. This would also allow the Unix user to have "local"
components that could be shared by any copy of mozilla they run by having them
registered under some common key.

This would not solve the problem of running two copies at the same time, but
would help in running multiple copies sequentially.
(Assignee)

Updated

20 years ago
Target Milestone: M8 → M9
(Assignee)

Comment 12

20 years ago
*** Bug 4275 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 13

20 years ago
*** Bug 7277 has been marked as a duplicate of this bug. ***

Updated

20 years ago
Hardware: Macintosh → All

Comment 14

20 years ago
*** Bug 7363 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
Target Milestone: M9 → M8
(Assignee)

Comment 15

19 years ago
This should be possible now. Actually if you get lucky, simultaneous should be
possible too.

Updated

10 years ago
Component: XPCOM Registry → XPCOM
QA Contact: dp → xpcom
You need to log in before you can comment on or make changes to this bug.