19434 - Mozilla silently quits if main1 returns error

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Cmd-line Features, defect, P2)

Description

[Simon Fraser [no longer active]]

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.

Comment 1

[racham]

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 ***

Comment 2

[Simon Fraser [no longer active]]

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.

Comment 3

[leger]

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

Comment 4

[racham]

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.

Comment 5

[kmurray1115]

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

Comment 6

[racham]

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.

Comment 7

[racham]

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.

Comment 8

[Conrad Carlen (not reading bugmail)]

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.

Comment 9

[Conrad Carlen (not reading bugmail)]

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. 

Comment 10

[Asa Dotzler [:asa]]

over to Pavlov, cc:'ing law

Comment 11

[Stuart Parmenter]

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?

Comment 12

[Simon Fraser [no longer active]]

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

[Stuart Parmenter]

mm, good native code... (sigh).  So who wants this bug?

Comment 14

[Conrad Carlen (not reading bugmail)]

*** Bug 53637 has been marked as a duplicate of this bug. ***

Comment 15

[rubydoo123]

removing myself from the cc list

Comment 16

[Frankie]

2 years later... is this bug still relevant?

Comment 17

[Simon Paquet [:sipaq]]

This bug is not Mac classic only. 
Hardware -> ALL
OS -> ALL

Comment 18

[Joel Nackman]

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.

Comment 19

[timeless]

[e-mail]: 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

Comment 20

[Joel Nackman]

(In reply to comment #19)
> [e-mail]: 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

[Benjamin Smedberg]

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.