I just deleted one of my profiles, and now profileMgr->StartupWithArgs() is returning an error. If this happens, the app silently quits when you try to run it. You need to show an error dialog in this situation.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE
This is the case where the current profile value is set to blank on it's way out and never to set/pick a valid value when we run the app again. This is same as bug 19030. Marking it as a dup. This wil be fixed when changes for 15042 gets checked in. *** This bug has been marked as a duplicate of 19030 ***
NO! This bug is not about a specific problem that might cause profile initialization to fail. It's about the fact that if *anything* causes profile init to fail, the app fails silently. We need an error dialog, or some default behaviour, or something.
Moving all Profile Manager bugs to new Profile Manager Backend component. Profile Manager component to be deleted.
Error conditions in the cases where there is no JS interface like automigration are covered with default behavior like creating a new silent profile on failure. Other failures like rename, delete are covered via java script error dialog. The re might be some more cases like no disk space to create or load profiles. Considering such cases as remote, I am moving this bug to M15.
Target Milestone: M14 → M15
Not much activity on this lately. I'd like to move this to Future. Bhuvan, your thoughts?
We do take care of out of disk space errors now (with propmt dialogs). Failure during automigration are taken care with creation of default profile. If the profie directory is missing (if the profile directory is physically deleted), we recreate the path and proceed to launch the browser. Certainly many of these weren't happneing at the time this bug was filed. Right now, we do still have few cases (general component failures) to be caught and to be informed. But not critical enough to be considered for beta3. Moving the milestone to future.
Target Milestone: M18 → Future
Doing a mass reassign to Conrad Carlen. Conrad is going address all current and upcoming profile manager issues. Please do not hesitate to involve me in any of the issues.
Assignee: racham → ccarlen
Status: REOPENED → NEW
As far as profile mgr is concerned, it has sufficent fallback and default mechanisms to prevent StartupWithArgs from failing. If one is found, a more specific bug needs to be filed on that. Agreed that we need a way to pop an error dialog at start-up time - even if low level initialization failed, but that it not a profile mgr issue.
Re-assingning and changing summary. Since we're talking about what happens after we've returned from profile mgr at startup, it can't be the fault of profile mgr. If anything in nsAppRunner::main1() fails, we'll die silently. We need a way to pop fatal start-up error dialogs.
Assignee: ccarlen → asa
Component: Profile Manager BackEnd → Browser-General
QA Contact: gbush → doronr
Summary: Mozilla silently quits if profileMgr->StartupWithArgs() returns error → Mozilla silently quits if main1 returns error
over to Pavlov, cc:'ing law
Assignee: asa → pavlov
There are numerous conditions in which it fails and we *can't* bring up a window since things didn't get loaded, or called, that we require to bring up windows. I'm not sure how we should fix this. I don't think there is a good way. Also, I don't think I should own this... anyone know who should?
Sure we can bring up a window (on Mac and Windows, at least); we just use a native dialog. You can use console output on Unix, since you don't have a toolkit loaded yet.
mm, good native code... (sigh). So who wants this bug?
*** Bug 53637 has been marked as a duplicate of this bug. ***
removing myself from the cc list
2 years later... is this bug still relevant?
This bug is not Mac classic only. Hardware -> ALL OS -> ALL
OS: Mac System 8.5 → All
Hardware: Macintosh → All
Reporter, This bug was filed over 6 years ago, so I am going to mark it INVALID. However, if you feel that this bug is still relevant, please contact me so I can reopen it.
Status: NEW → RESOLVED
Last Resolved: 19 years ago → 14 years ago
Resolution: --- → INVALID
firstname.lastname@example.org: i'm glad to see new blood volunteering to working on mozilla, but please consider checking to see if code bugs are valid before you do something as silly as this again. if you'd like to volunteer to fix this bug, please let me know. offhand i think a couple of these returns are entirely bogus http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/xpfe/bootstrap/nsAppRunner.cpp&rev=1.433&mark=1199,1171#1169
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Assignee: pavlov → nobody
Status: REOPENED → NEW
Component: General → Cmd-line Features
Product: Mozilla Application Suite → Core
QA Contact: doronr
(In reply to comment #19) > email@example.com: i'm glad to see new blood volunteering to working on > mozilla, but please consider checking to see if code bugs are valid before you > do something as silly as this again. > > if you'd like to volunteer to fix this bug, please let me know. > > offhand i think a couple of these returns are entirely bogus > http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/xpfe/bootstrap/nsAppRunner.cpp&rev=1.433&mark=1199,1171#1169 Sorry, I was being stupid.
The bootstrap code is a lot more resilient now. Not that you couldn't end up with a silent failure, but it's a lot harder. If somebody encounters something like this, please file a new bug with specific details.
Status: NEW → RESOLVED
Last Resolved: 14 years ago → 10 years ago
Resolution: --- → INCOMPLETE
Component: Cmd-line Features → Cmd-line Features
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.