While investigating smoketest blocker #122228, Tracy posted a stack trace which showed his mail accounts getting loaded on startup of a new browser window. That is from the profile manager, the first window to come up is a browser window. Yet we are loading mail accounts. You can see that behavior here in the stack: nsMsgAccountManager::LoadAccounts [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgAccountManager.cpp, line 1294] nsMsgAccountManager::GetAccounts [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgAccountManager.cpp, line 1113] 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 2000] XPC_WN_GetterSetter [d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp, line 1299] js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 834] js_InternalInvoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 925] js_GetProperty [d:\builds\seamonkey\mozilla\js\src\jsobj.c, line 2448] js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2633] js_Execute [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 1014] JS_ExecuteScript [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 3253] nsJSContext::ExecuteScript [d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 824] nsXULDocument::ExecuteScript [d:\builds\seamonkey\mozilla\content\xul\document\src\nsXULDocument.cpp, line 6206] nsXULDocument::OnStreamComplete [d:\builds\seamonkey\mozilla\content\xul\document\src\nsXULDocument.cpp, line 6142] nsStreamLoader::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamLoader.cpp, line 163] nsJARChannel::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\protocol\jar\src\nsJARChannel.cpp, line 614] nsOnStopRequestEvent::HandleEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsRequestObserverProxy.cpp, line 213] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 591] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 524] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 1072]

I wonder if the profile Tracy selected required migration or activation? Maybe that's why we were loading the mail accounts before brining up the browser window.

it's possible this is from a migrated profile. I generated talkback for several crashes this morning. the one I posted may have been from the migrated profile.

here's a stack from a NS6 profile: nsAppShellService::GetHiddenDOMWindow [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp, line 608] nsMessengerWinIntegration::InitializeBiffStatusIcon [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMessengerWinIntegration.cpp, line 186] nsMessengerWinIntegration::Init [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMessengerWinIntegration.cpp, line 201] nsMessengerWinIntegrationConstructor [d:\builds\seamonkey\mozilla\mailnews\base\build\nsMsgFactory.cpp, line 325] nsGenericFactory::CreateInstance [d:\builds\seamonkey\mozilla\xpcom\components\nsGenericFactory.cpp, line 77] nsComponentManagerImpl::CreateInstanceByContractID [d:\builds\seamonkey\mozilla\xpcom\components\nsComponentManager.cpp, line 1670] nsComponentManagerImpl::GetServiceByContractID [d:\builds\seamonkey\mozilla\xpcom\components\nsComponentManager.cpp, line 2061] nsGetServiceByContractID::operator() [d:\builds\seamonkey\mozilla\xpcom\components\nsComponentManager.cpp, line 247] nsCOMPtr_base::assign_from_helper [d:\builds\seamonkey\mozilla\xpcom\glue\nsCOMPtr.cpp, line 81] nsMsgAccountManager::LoadAccounts [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgAccountManager.cpp, line 1294] nsMsgAccountManager::GetAccounts [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgAccountManager.cpp, line 1113] 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 2000] XPC_WN_GetterSetter [d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp, line 1299] js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 834] js_InternalInvoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 925] js_GetProperty [d:\builds\seamonkey\mozilla\js\src\jsobj.c, line 2448] js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2633] js_Execute [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 1014] JS_ExecuteScript [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 3253] nsJSContext::ExecuteScript [d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 824] nsXULDocument::ExecuteScript [d:\builds\seamonkey\mozilla\content\xul\document\src\nsXULDocument.cpp, line 6206] nsXULDocument::OnStreamComplete [d:\builds\seamonkey\mozilla\content\xul\document\src\nsXULDocument.cpp, line 6142] nsStreamLoader::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamLoader.cpp, line 163] nsJARChannel::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\protocol\jar\src\nsJARChannel.cpp, line 614] nsOnStopRequestEvent::HandleEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsRequestObserverProxy.cpp, line 213] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 591] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 524] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 1072] KERNEL32.DLL + 0x24407 (0xbff94407) 0x00688972

I crashed also..my stack trace is the same. I was using 2002-01-28-10-trunk/ on NT 4.0 I did a clean install before installing and when profile mgr came up, I chose a profile to migrate, and then it crashed. talkback id 2230518

I think I have a fix which should at least cause the biff icon to work correctly even when the accounts are loaded before the hidden window is created. However we should still investigate why we are loading the mail accounts right after tracy chooses his profile. If it is happening because he is going through migration or through activation then that would make sense. If he isn't doing that then we need to figure out why.

since I'm testing commercial bits, I do get the activation screen. But I always cancel...cancel the two dialogs so that I'll not see the activation screen again. same goes for migrated profiles.

Comment on attachment 66960 [details] [diff] [review] delay creating biff icon structures until we really need them r=bhuvan. One thing that we can do to narrow down the problem is to try to reproduce this with mozilla builds. That will tell us the role activation is playing here. If can't be reproduced in mozilla, then activation is first component to look at. Otherwise, we can start with migration.

Comment on attachment 66960 [details] [diff] [review] delay creating biff icon structures until we really need them got an sr=sspitzer on this

I checked this fix in. Tracy I'm betting that on the profile & machine that had this problem (after I fixed the crash of course), you never got a biff icon in the system tray for that profile when new mail arrived. Hopefully after what I just checked in you will now see the icon again. I'll file another bug on Seth to track down why your accounts are getting loaded coming out of the profile manager.

I was also bitten by this crash the day of this smoketest blocker. When the new build came out, this worked for me. 2002-01-28-10 was the last build that this crash occurred. Verified FIXED - but did we ever find out or file the bug for 'loading mail accounts before startup'?