79471 - Browser is launched before profile manager is done

Status: VERIFIED DUPLICATE of bug 86423

(SeaMonkey :: Startup & Profiles, defect, P2)

Description

[german]

on Mac using today's 2001050808 commercial build (assume the same on Mozilla)
the browser is launched before the profile manager is dismissed after having
selected a profile. This represents a severe privacy and security issue.
The browser comes up empty in terms of bookmarks and sidebar panels. There seem
to be bugs filed related to this. Right now I am only seeing this on Mac.
Will be attaching screenshot.

Comment 1

[german]

Attachment: screenshot shweoing both profile mgr and browser open after launch

Comment 2

[german]

attaching screenshot and upping priority, keyword and severity

Comment 3

[Grace Bush]

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

Comment 4

[Ben Goodger (use ben at mozilla dot org for email)]

Is this still happening? This doesn't sound like my bug. 

Comment 5

[Adam Lock]

It certainly is on Win32 so I'm changing the target platform and OS to all.

Launch Mozilla with two or more profiles and while in the profile selection 
dialog, launch Mozilla again. Second Mozilla tells the first to open a browser 
window which it does even though the profile hasn't been chosen yet.

Comment 6

[selmer (gone)]

Adding danm to CC list.  Dan, the profile manager gets into its UI with a Run()
statement.  It only procedes to the main nav window when that statement returns.
 Any theory on how it could both return and not return at the same time?  Anyone
else who should be pulled into this one?

Comment 7

[Dan M]

Isn't it true that the Mozilla launched second sends a DDE message to the first? 
Mozilla probably just needs to pay no attention to DDE while it's deciding 
profiles.

Comment 8

[Bill Law]

Hah, I thought the "window watcher" would just pay no attention to requests to
open a new browser window while the profile manager is still deciding what to do.

I guess I'll have to add code to deal with this.  I think I'll just have
incoming requests (no longer DDE, BTW) focus the already visible profile manager
window.

Comment 9

[Viswanath Ramachandran]

nav+pdt triage: moving to m0.9.2. 

Comment 10

[Bill Law]

Need to add code here:
http://lxr.mozilla.org/seamonkey/source/xpfe/bootstrap/nsNativeAppSupportWin.cpp
#932

that determines whether a profile has been selected and if not, either ignores 
the request or finds the profile manager window and focuses it.

Comment 11

[Conrad Carlen (not reading bugmail)]

Bill, Not responding to incoming requests at the code you mention will do it (at
least for Windows). Question is: Should a request to open a new browser window
be handled while *any* modal window is frontmost? It might be more general,
easier, and more correct to get the active window from window watcher, see if it
is modal, and act on that rather then being dependent on what state the profile
mgr is in.

Comment 12

[Bill Law]

Maybe.  But "modal" means different things and I'm not sure that having a modal
window topmost should block all new requests.  Since we're only opening
stand-alone top-level windows, maybe it's OK if some other window is disabled
because it has a pop-up dialog.  We won't be messing with that window.

Is that platform dependent?  We're really only talking Windows with respect to
this bug (although maybe it's an issue on Mac, too?).

Comment 13

[Bill Law]

Assigning to Samir because he's less doomed and can help out on the Mac side.  
Samir, please don't hesitate to contact me about details of the Win32 fix.

Comment 14

[Samir Gehani]

Cannot reproduce the originally reported bug per German's steps.  I have two
mozilla profiles and used a mozilla debug build and a N6.1b1 opt build to test.  
So I went ahead and tried the steps Adam mentions about launching mozilla again
while the profile manager is up (although he saw that on Windows and German
reported this on Mac): the profile manager is given focus and no new navigator
window pops up as seen in German's screen shot.

German,
Are you still seeing this on the mac?  If so, any additional steps to reproduce
that I am missing?  Could I look at your machine if this is still happening as
originally reported?  Thanks.

Changing platform to Windows for now since I intend to only address the Windows
bug mentioned.

Comment 15

[Viswanath Ramachandran]

-> morse

Comment 16

[Conrad Carlen (not reading bugmail)]

A fix for this is rolled into the fix for bug 86021. Also, now that I'm reminded
of this bug, bug 86423 is a likely dup of this one. 

Comment 17

[Samir Gehani]

Whew!  Thanks for getting this one of my plate Conrad!

*** This bug has been marked as a duplicate of 86423 ***

Comment 18

[Grace Bush]

Verified as duplicate