I know there is a general bug (99117) for mailnews problems using turbo, but that bug is getting long and has scenarios other than this one. If it's a dup, mark it as such, but this scenario needs to be tested too when fixed. 1.) I have (3) Profiles (see attached html I've included in this bug). 2.) I launched profile "3qates07" and while in that profile, I enabled "Quick Launch" via the prefernce and then Exited the app. 3.) I launch profile "esther" and open mail. Result: to my suprise the Mail folder pane shows (2) esther_goes@netscape.com accounts (I should only have 1), but the first one is showing the folders for 3qatest07 which is the account of the previous profile. 4.) I then open Account Settings and see that it's showing (2) esther_goes@netscape.com accounts too. This is very bad. I haven't acutally tried the bogus account in my "esther" profile to see what happens when I try to send or receive mail, but I expect if the user gets into this state they will run into trouble. This profile confusion really needs to be fixed.

Screen shots are not displaying -

->ccarlen (since it is really a profile issue, during QuickLaunch)

nominating nsbeta1 since this may be an issue for internal enterprise deployment. We are getting more calls / questions on folks having problem with adding multiple accounts in QuickLaunch mode.

cc'in scott putterman to keep in the loop. Also note: Mailnews QA uses multiple profile all the time. When switching profiles for testing purposes we have to remember to Exit Turbo before switching then Turn Turbo back on when we're in the other profile. This can be time consuming, especially if we forget to disable it when switching and we start running into the flaky behavior.

nsbeta1+, this blocks enabling turbo for MachV, well as slowing down QA testing. Conrad, could you please target this so we know you are aware of it, and will handle it in time?

This sounds very similar to the problem of bug 99117. Since the scenario here is a little different, making that one, since it's more general, depend on this.

Using build 20020401 on winxp this is still a problem. I noticed that bug 99117 was fixed on 3-26 but not verified yet. If a fix went in for that problem, it did not fix this problem.

This shows a list of Profiles I have. Note Turbo was turned on via Preference when I was in "3qatest07" profile. I exited and relaunched to open my "esther" profile.

This picture shows what happened to my Mail for the "esther" Profile. Note, I have (2) esther_goes@netscape.com accounts listed (I should only have one), however the 1st one shows the folders for the 3qatest07 account in the previously opened profile titled "3qatest07".

This is what Account Settings was showing, it was messed up too.

Disregard comment 11 and attachment 77141 [details], it's in plain text and shouldn't be. You don't need this attachment to see the mixed up folder list.

This is not dependent on or a dup of 99117, that one is fixed and verified, this bug still exists. Please get this on the adt radar. Note: I'm also seeing Send failing on a profile created after using the current profile in turbo, may be related but I'm logging a new bug to keep these issues from getting lost.

Marking [adt2]. Cavin, could you help look into this one as well?

We now crash when doing this. Need to fix the crash before we can test this scenario. Talkback msvcrt.dll + 0x335d2 (0x77c435d2) nsMsgIMAPFolderACL::BuildInitialACLFromCache [d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapMailFolder.cpp, line 5000] nsMsgIMAPFolderACL::nsMsgIMAPFolderACL [d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapMailFolder.cpp, line 4965] nsImapMailFolder::GetFolderACL [d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapMailFolder.cpp, line 6467] nsImapMailFolder::GetCanIOpenThisFolder [d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapMailFolder.cpp, line 4943] nsImapMailFolder::UpdateFolder [d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapMailFolder.cpp, line 676] XPTC_InvokeByIndex [d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp, line 106] XPCWrappedNative::CallMethod [d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp, line 2027] XPC_WN_CallMethod [d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp, line 1267] js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 790] js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2746] js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 806] js_InternalInvoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 881] JS_CallFunctionValue [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 3414] nsJSContext::CallEventHandler [d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 1019] nsJSEventListener::HandleEvent [d:\builds\seamonkey\mozilla\dom\src\events\nsJSEventListener.cpp, line 182] nsEventListenerManager::HandleEventSubType [d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line 1218] nsEventListenerManager::HandleEvent [d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line 1821] nsXULElement::HandleDOMEvent [d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3461] nsTreeSelection::FireOnSelectHandler [d:\builds\seamonkey\mozilla\layout\xul\base\src\tree\src\nsTreeSelection.cpp, line 738] nsTreeSelection::Select [d:\builds\seamonkey\mozilla\layout\xul\base\src\tree\src\nsTreeSelection.cpp, line 369] XPTC_InvokeByIndex [d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp, line 106] XPCWrappedNative::CallMethod [d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp, line 2027] XPC_WN_CallMethod [d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp, line 1267] js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 790] js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2746] js_Execute [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 970] JS_EvaluateUCScriptForPrincipals [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 3365] nsJSContext::EvaluateString [d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 677] GlobalWindowImpl::RunTimeout [d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 4207] GlobalWindowImpl::TimerCallback [d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 4572] nsTimerImpl::Process [d:\builds\seamonkey\mozilla\xpcom\threads\nsTimerImpl.cpp, line 330] handleMyEvent [d:\builds\seamonkey\mozilla\xpcom\threads\nsTimerImpl.cpp, line 381] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 597] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 530] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 1078] USER32.dll + 0x3c076 (0x77d7c076) USER32.dll + 0x3c076 (0x77d7c076) _except_handler3() kernel32.dll + 0x3bb86 (0x77e9bb86)

Yes, it did crash twice on me when I tried to reproduce the problem. The crash happened when I launched the 2nd profile. The build is from 04/02.

cc'ing David. Should we get a new bug for the crash?

there's already a bug filed for this crash, but that bug doesn't have any steps for reproducing the problem - this crash is reproducible, then? See bug 134097 for the same stack trace.

this works fine for me now, and also for Cavin. Esther, does it work for you with recent builds (if you can get one with turbo working...)

Just got a build with turbo working, am testing now will update when I finish testing

Using build 2002041306 on win ME, I created some profiles similiar to the profiles I have on my WinXP system (the system I saw this problem on). I ran through the scenario: The profile switching was OK for this specific scenario (I'll log a new bug for the problem I did see regarding addding new mail accounts to one of the profiles). Also, I did not crash. I believe this is fixed now, the fix for bug 134274 may have fixed this also, not sure though.

Fixed - as a side-affect of something else.

not seeing this on 2k - trunk for 6/5 or branch for 6/6