Closed
Bug 53751
Opened 25 years ago
Closed 25 years ago
Crash after selecting "Finish" in Account Wizard
Categories
(SeaMonkey :: MailNews: Account Configuration, defect, P3)
Tracking
(Not tracked)
People
(Reporter: nbaca, Assigned: trudelle)
Details
(Keywords: crash, platform-parity)
Build using the Commercial's install files on 9/21.
Navigators title area shows Build ID: 2000-09-1312, not sure why.
Overview: Add a new account using the Account Wizard. On it's last dialog select
the "Finish" button.
Actual Results: A crash occurs immediately. After restarting the application
then the account is present and working.
Expected Results: No crash should occur.
Additional Information:
- Crash occurs when adding a POP, IMAP or News account.
- Crash occurs in a new or migrated profile.
- No Crash on NT4 or Mac
![]() |
Reporter | |
Comment 1•25 years ago
|
||
Marking nsbeta3 because adding a new account should not result in a crash.
![]() |
||
Comment 2•25 years ago
|
||
can I get a stack trace? I'll bet this is the exact same crash as the Cancel
button crash.
![]() |
Reporter | |
Comment 3•25 years ago
|
||
Incident# 17866535
Call Stack: (Signature = 0x00000000 b17993e6)
0x00000000
nsHTMLImageLoader::ImageLoadCB()
nsFrameImageLoader::NotifyFrames()
nsFrameImageLoader::Notify()
ns_observer_proc()
XP_NotifyObservers()
il_image_complete_notify()
il_image_complete()
ImgDCallbk::ImgDCBHaveImageAll()
process_buffered_gif_input_data()
gif_delay_time_callback()
timer_callback()
nsTimerGtk::FireTimeout()
process_timers()
TimerCallbackFunc()
libglib-1.2.so.0 + 0x108a4 (0x4088f8a4)
libglib-1.2.so.0 + 0xfa86 (0x4088ea86)
libglib-1.2.so.0 + 0x10041 (0x4088f041)
libglib-1.2.so.0 + 0x100f4 (0x4088f0f4)
nsAppShell::DispatchNativeEvent()
nsXULWindow::ShowModal()
nsWebShellWindow::ShowModal()
nsChromeTreeOwner::ShowModal()
GlobalWindowImpl::OpenInternal()
GlobalWindowImpl::OpenDialog()
WindowInternalOpenDialog()
js_Invoke()
js_Interpret()
js_Invoke()
js_InternalInvoke()
JS_CallFunctionValue()
nsJSContext::CallEventHandler()
nsJSEventListener::HandleEvent()
nsEventListenerManager::HandleEventSubType()
nsEventListenerManager::HandleEvent()
nsXULElement::HandleDOMEvent()
PresShell::HandleDOMEventWithTarget()
nsMenuFrame::Execute()
nsMenuFrame::HandleEvent()
PresShell::HandleEventInternal()
PresShell::HandleEvent()
nsView::HandleEvent()
nsView::HandleEvent()
nsView::HandleEvent()
nsView::HandleEvent()
nsViewManager2::DispatchEvent()
HandleEvent()
nsWidget::DispatchEvent()
nsWidget::DispatchWindowEvent()
nsWidget::DispatchMouseEvent()
nsWidget::OnButtonReleaseSignal()
nsWindow::HandleGDKEvent()
dispatch_superwin_event()
handle_gdk_event()
libgdk-1.2.so.0 + 0x170fb (0x408640fb)
libglib-1.2.so.0 + 0xfa86 (0x4088ea86)
libglib-1.2.so.0 + 0x10041 (0x4088f041)
libglib-1.2.so.0 + 0x101e1 (0x4088f1e1)
libgtk-1.2.so.0 + 0x8b7a9 (0x407bb7a9)
nsAppShell::Run()
nsAppShellService::Run()
main1()
main()
libc.so.6 + 0x17cb3 (0x40257cb3)
![]() |
||
Comment 4•25 years ago
|
||
weird stack trace, but over to xptoolkit for gtk window issues and CC pnunn for
image issues
Assignee: alecf → trudelle
![]() |
Reporter | |
Comment 6•25 years ago
|
||
Marina, what build are you using on the Mac? I was using the 9/21 build.
![]() |
||
Comment 7•25 years ago
|
||
That is the identical stack trace for bug 53517, evaughan's fix from yesterday.
Not crashing in today's Linux build (or win2k for that matter). Marking
duplicate. Please reopen if this is still an issue.
*** This bug has been marked as a duplicate of 53517 ***
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
![]() |
Reporter | |
Comment 9•25 years ago
|
||
Verified Duplicate,
Also checked the latest build and it no longer crashes. Using Branch Build
2000-09-27-11MN6: NT4, Linux 6.0, Mac 9.04.
Updated•21 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•