Closed Bug 62418 Opened 24 years ago Closed 23 years ago

Mozilla Starts even if Profile Directory is Missing

Categories

(Core Graveyard :: Profile: BackEnd, defect, P1)

Product:
Core Graveyard
Component:
Profile: BackEnd
Platform:
x86
Other
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.1

People

(Reporter: brian, Assigned: ccarlen)

References

Details

Attachments

(3 files)

patch to force UI to come up when prof dir is missing
10.28 KB, patch
Details | Diff | Splinter Review
updated patch
9.52 KB, patch
Details | Diff | Splinter Review
updated (again) patch
2.90 KB, patch
Details | Diff | Splinter Review 
Build 2000120704 Windows MTrunk

If the profile directory does not exist, Mozilla starts anyway in the classic
skin (with no preferences).  There should be a warning displayed and mozilla
probably should not start.

Then, if the directory is replaced and Mozilla is started with that profile,
Mozilla still starts without any of your past preferences (like the directory
does not exist at all).  To fix this you have to remove the profile (don't
delete the files) and then re-create the profile in the same directory.  Thanks!
 Keep up the good work!
possible related to bug 47023
I think that a warning should appear with a message like "profile does not
exist" and then 2 choices "start anyway" and "cancel".
Not to start at all would be bad in situations, where you do not have a profile
and you just want the browser to start...
On the other hand, on my linux version a special wizard (?) appeared, which
asked, if you want to create a new profile or want to take a NS4-profile...


This does have an additional bug to it than 47023 has.  If you start Mozilla
with a profile missing and then try to start Mozilla with the profile there, the
settings are never read again.  You have to recrate the profile to get it to
read the settings.  I agree, there should be an option like described above.
Maybe with another option that asks should the profile be removed?
I agree. When a profile directory is missing, we should not just silently create
a profile directory for that profile. We should prompt with a file picker like
4.x did. That would allow somebody to locate it if they moved it, kept it on
removable media, etc. This is different from the case of not having a profile at
all simply because the program has not been run. In this case, a default profile
should just be made as is done now.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → mozilla0.8
The above patch does the following:
(1) If we have only one profile (in which case no UI would come up), the
back-end ensures that its dir exists and if not, forces the UI to come up.
(2) Whenever the UI is up and the user selects a profile, it ensures that the
profile dir exists and warns the user if not. It makes it impossible to select a
profile for which the dir is missing.

It stops short of doing the whole 4.x behavior. It doesn't prompt the user to
find the dir. I'll look into this next but think it will be a problem for
platforms which store absolute path names in the prefs.

Even without this, it is still an improvement over the current behavior where a
new default profile is made and the user isn't even told about it but just has
to wonder what happened to their settings.

Bhuvan - Can you review?
Conrad,

With this patch, if the directory is missing, to proceed further the user need
to either manually create the directory (which is bit difficult to findout as
it's in the registry) or delete that profile...? is that right..? If so, we
probably need a mechanism to recreate the dir for the user. what do you think..?
The error message that comes up advises to either pick another profile or create
a new one. Creating a new one does not try to recreate the old one, delete the
old one from the registry, or anything destructive. Since the "Create Profile"
button is right there, it's easy to do. At this point, it's more of a warning
that the dir is missing and the idea is to not recreate something by default or
overwrite the registry entry of the missing profile. With just a little work, it
could ask the user to find it or ask them if they want to delete it.
*** Bug 24147 has been marked as a duplicate of this bug. ***
r=racham.

What is implemented here is good enough for now as it lets user know about the
condition. We shall sure aim for displaying the message like 4.x did. That will
be great. Will open a separate bug on that one.

New bug to take care of the situation with advanced UI is bug 64832.
Ben, can you give sr?
Keywords: review
*** Bug 47023 has been marked as a duplicate of this bug. ***
-> mozilla 0.9
Target Milestone: mozilla0.8 → mozilla0.9
Blocks: 40316
Adding Seth to cc list.
two comments:

1) you removed these lines:

-    PRBool shrimpPrefEnabled = PR_FALSE;
-    prefs->GetBoolPref(SHRIMP_PREF, &shrimpPrefEnabled);

how is SHRIMP affected by this change?

2)

+      alertString = alertString.replace(/%brandShortName%/gi, 
brandBundle.GetStringFromName("brandShortName"));
+      alertString = alertString.replace(/%name%/gi, profilename);

don't do that.  see bug #69433 for a patch that does it the right way.

I see the %foo% / replace stuff a couple places in mozilla/profile.  fixing it is 
another bug, but we shouldn't add more js that does it.

Note also that the existing patch depends on a bundle that doesn't exist there
anymore.  The replace(/%foo%/) code can (should) use the getFormattedString
method of the stringbundle instead.
> 1) you removed these lines:

> -    PRBool shrimpPrefEnabled = PR_FALSE;

The profile mgr is not used at all with Shrimp. There is a bug somewhere on
removing refs to it from profile code but I just did it here.

> don't do that.  see bug #69433 for a patch that does it the right way.

I'll do that and post another patch.


Here's a new patch - the previous one was very old. The new one uses
getFormattedString.
    * The following 2 methods are deprecated. DO NOT USE THEM.
why not The following methods are deprecated. DO NOT USE THEM.
or do we really need a blamed line each time the number of deprecated methods 
changes?
Conrad, 

As mentioned by timeless mentioned, we can simply have following have been
deprecated and move all those still holding good above that..The only drawback
with that one will be if any one accedentally adds a new interface below these
deprecated interfaces. So, you may have "deprecated methods : begin" and ": end"
block covering all depercated methods if you feel that's going to make things
any better...Anyway, it's a pretty small change. Try to accommodate this.

r=racham (new patch).


Alright - I moved the deprecated methods to the bottom of the iface and said:
"The remaining methods are deperecated..." I wouldn't worry about it too much
because those methods can be removed soon.
Seth there's a new patch with your suggestions about getFormattedString. Can you sr?
"profDirMissing=%1$S cannot use the profile "%2$S" because the directory
containing the profile cannot be found.<html:br/><html:br/> Please choose
another profile or create a new one."

is %x$S necessary?  Why not just %S?

that <html:br/> stuff, yuck.  but I know we do that all over in the profile.js

until we fix it, can you add a localization note to tell the person not to
localize "<html:br/>"?

OK, once more. The update to this patch has Bhuvan & timeless' suggestion about
commenting deprecated routines in nsIProfileInternal.idl and Seth's suggestion
about localization comments and %S vs. %x$S. All I need is a sr. Seth?


Still needs sr=. Will check in as soon as tree opens for 0.9.1
Target Milestone: mozilla0.9 → mozilla0.9.1
Upping priority so I'll check it in as soon as 0.9.1 opens.
Priority: P3 → P1
Fixed checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Keywords: review
Resolution: --- → FIXED
verifying with build for 20010530
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: