Commercial trunk 2001-08-13-09-trunk/ Nt 4.0 2001-08-13-08-trunk/ linux 2.2, mac 9.0.4 Only tested this on windows but I assume same result would happen on any platform. This came about from a rare offline test case scenario/crash (bug 94198). So i started thinking about other rare/weird situations. What if the user creats new profile, cancels web mail activation, and cancels Account setup screen but then decides to click on either: 'New mesg button', File|New|mesg from Messenger or Browser. And when the Account set up screen appears again, the user cancels. The result is a crash. Steps to reproduce: 1.create brand new profile 2.do not activate web mail account 3.start browser a.file|new| mesg b.cancel account setup and then click ok when it asks you are you sure you want to cancel. result: crash 4.(if you skip step 3) 5.start messenger 6.Cancel Account setup and IM setup 7.click ok when it asks you are you sure you want to cancel. 8.Click on New Mesg button or file|new|mesg 9.Repeat steps 6 and 7 result: crash I know this is a RARE case as the odds of someone doing this I think are nill but probably should still be fixed? Talkback ids TB34076905Y, TB34076889M http://climate.mcom.com/reports/incidenttemplate.cfm?bbid=34076588 Stack Trace: GlobalWindowImpl::RunTimeout [d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 3419] nsGlobalWindow_RunTimeout [d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 3701] nsTimer::Fire [d:\builds\seamonkey\mozilla\widget\timer\src\windows\nsTimer.cpp, line 196] nsTimerManager::FireNextReadyTimer [d:\builds\seamonkey\mozilla\widget\timer\src\windows\nsTimerManager.cpp, line 117] FireTimeout [d:\builds\seamonkey\mozilla\widget\timer\src\windows\nsTimer.cpp, line 91] USER32.dll + 0x185c (0x77e7185c) nsAppShellService::Run [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp, line 425] netscp6.exe + 0x174d (0x0040174d) netscp6.exe + 0x121a (0x0040121a) netscp6.exe + 0x368f (0x0040368f) KERNEL32.dll + 0x1ba06 (0x77f1ba06)
17 years ago
The real bug here is that all items (except Mail/news Account Settings) should be disabled if no accounts are available. That issue is a duplicate, of some other already-filed bug though. Luckily, most of the items *are* disabled if you try to reproduce this bug today. I tried, with a new profile. Most of mailnews was disabled as expected, but New Message wasn't. This is of course a bug, but it didn't crash. I played around with mailnews for a while and couldn't get any of the enabled items to make it crash. This is worksforme, since I can't crash, but feel free to file new bugs on the items that should be disabled if there are no accounts available/selected.
marking as verified works for me since 4-10 branch builds don't show this crash