Mozilla silently quits if main1 returns error

RESOLVED INCOMPLETE

Status

P2
major
RESOLVED INCOMPLETE
19 years ago
10 years ago

People

(Reporter: sfraser_bugs, Unassigned)

Tracking

Trunk
Future

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

19 years ago
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.

Updated

19 years ago
Assignee: selmer → racham

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M13

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE

Comment 1

19 years ago
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 ***

Updated

19 years ago
Status: RESOLVED → VERIFIED
(Reporter)

Updated

19 years ago
Status: VERIFIED → REOPENED
(Reporter)

Updated

19 years ago
Resolution: DUPLICATE → ---
(Reporter)

Comment 2

19 years ago
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.

Updated

19 years ago
Target Milestone: M13 → M14

Updated

19 years ago
Component: Profile Manager → Profile Manager BackEnd

Comment 3

19 years ago
Moving all Profile Manager bugs to new Profile Manager Backend component.
Profile Manager component to be deleted.

Comment 4

19 years ago
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

Updated

19 years ago
Severity: normal → major
Priority: P3 → P2
Target Milestone: M15 → M16

Updated

19 years ago
Target Milestone: M16 → M17

Updated

19 years ago
Target Milestone: M17 → M18

Comment 5

19 years ago
Not much activity on this lately. I'd like to move this to Future. Bhuvan, your 
thoughts?

Comment 6

19 years ago
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

Comment 7

18 years ago
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

Comment 10

18 years ago
over to Pavlov, cc:'ing law
Assignee: asa → pavlov

Comment 11

18 years ago
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?
(Reporter)

Comment 12

18 years ago
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.

Comment 13

18 years ago
mm, good native code... (sigh).  So who wants this bug?
*** Bug 53637 has been marked as a duplicate of this bug. ***

Updated

18 years ago
Hardware: All → Macintosh

Comment 15

17 years ago
removing myself from the cc list

Comment 16

16 years ago
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
Product: Browser → Seamonkey

Comment 18

14 years ago
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 ago14 years ago
Resolution: --- → INVALID

Comment 19

14 years ago
joelnackman@gmail.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
Status: RESOLVED → REOPENED
Resolution: INVALID → ---

Updated

14 years ago
Assignee: pavlov → nobody
Status: REOPENED → NEW
Component: General → Cmd-line Features
Product: Mozilla Application Suite → Core
QA Contact: doronr

Comment 20

14 years ago
(In reply to comment #19)
> joelnackman@gmail.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.

Comment 21

10 years ago
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 ago10 years ago
Resolution: --- → INCOMPLETE

Updated

10 years ago
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.