Closed Bug 23356 Opened 25 years ago Closed 25 years ago

Crash reading email after following link inside message

Categories

(SeaMonkey :: MailNews: Message Display, defect, P3)

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED WORKSFORME

People

(Reporter: jar, Assigned: phil)

Details

Although I can't provide an exact set of steps to consistently reproduce this bug, it is clearly the most likely cause for my crashes this week (first week of January). I have filed on different days about 3-7 talk back reports, and they all have this common element. The general scenario is: a) Read email for a while, doing deletes, and clicking on other messages in the subject pain b) Find/read a message with a URL c) Click on the URL in the message d) Bring the browser window to the forground e) optionally do some work in browser, such as bookmarking, or submitting a form f) Bring the mail window to the forground. g) Notice that the DELETE button is grey (inactive) h) Try giving focus (by clicking) on the body of the message. i) DELETE button is inactive still j) Select another message from the subject line pane k) DELETE button is still grey l) Select original message (that had link) m) Netscape crashes The above scenario is based on the commercial build. I always have AIM running before starting up email (it could relate to AIM :-/)
We'll try to reproduce this. (The DELETE button disabling is another bug that's already filed). Talkback is down so I can't go to the talkback reports to get the stack traces at this time.
Since today's Windows latest commercial build is not good, so I tried on 1-6-09-M13 commercial build. Yes. I am able to recreate this problem. It seemed that the delete button sometimes will disable when you tried to use URL on browsers.....
Karen - don't worry about the delete button. That's not what this bug is about. It's about the crash afterwards. Thanks.
I need to describe more clear.... I can recreate this problem for the delete button grey out. But, did not get the crash yet!!
I find (sadly) this bug can't be created by simply reading an email, following a link, and then going back to the message. I'm not sure of the exact context that triggers it, but it is happening to me A LOT. I think that looking at the stack trace in the talk-back reports will help to identify the area. For additional context: I'm always logged in via AIM while reading email. I read email for a while (5-20 messages), deleting some, saving others... and then I get adventuresome and try to follow a link. IMO, roughly 9 out of 10 times that I try to resume mail reading I crash. Alas, if I just open mail, follow a link, and then go back to mail... there is no crash :-( :-(. It happens SOOOOOO often that it must be a dominant element of talk back reports.
Talkback is taking a very long time (over 15 minutes) right now to display your reports. I'm wondering if you are running into that problem we had last week with displaying mail with vcards and crashing. I want to look at the stack trace, but still waiting for Talkback right now.
Win_nt 4.0 (2000-01-09-09 M13) I cannot reproduce the problem using the 1/9 build. I follow the same scenario, when I reach step g), the Delete button turns back to active. And continue on to the last step, application does not crash. I did this a couple of time. No crash. occurs.
I'm not seeing this, and I can't connect to cyclone right now
Hmm... I tried this on today's build, and it is not crashing. I'm now running W98 (rather than NT), and I do notice that the "Delete" button gets greyed out... but I can't get a crash. I can go back and forth, and can't "ungrey it" but I don't crash. At this point, I'm willing to see this marked "works for me" with the belief that the delete key greying was already in another bug. It would be nice if some of the talk-back reports were looked at, in case I mis classified the cause (but I sure thought the grey after following the link was critical :-/ ).
Talkback is still giving me errors when trying to access cyclone or climate.
Should we mark this wfm? I found talkback 3823640 from around this date with comments on deleting and following links. Crash/stack trace: 0x10a1def2 nsQueryInterface::operator() [d:\builds\seamonkey\mozilla\xpcom\base\nsCOMPtr.cpp, line 32] nsCOMPtr_base::assign_from_helper [d:\builds\seamonkey\mozilla\xpcom\base\nsCOMPtr.cpp, line 61] GlobalWindowImpl::GetPrivateParent [d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 3601] nsXULCommandDispatcher::GetControllerForCommand [d:\builds\seamonkey\mozilla\rdf\content\src\nsXULCommandDispatcher.cpp, line 523] XULCommandDispatcherGetControllerForCommand [d:\builds\seamonkey\mozilla\rdf\content\src\nsJSXULCommandDispatcher.cpp, line 438] js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 666] js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2227] js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 686] js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2227] js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 686] js_InternalCall [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 759] JS_CallFunctionValue [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 2754] nsJSContext::CallEventHandler [d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 564] nsJSEventListener::HandleEvent [d:\builds\seamonkey\mozilla\dom\src\events\nsJSEventListener.cpp, line 129] nsEventListenerManager::HandleEventSubType [d:\builds\seamonkey\mozilla\layout\events\src\nsEventListenerManager.cpp, line 639] nsEventListenerManager::HandleEvent [d:\builds\seamonkey\mozilla\layout\events\src\nsEventListenerManager.cpp, line 1402] nsXULElement::HandleDOMEvent [d:\builds\seamonkey\mozilla\rdf\content\src\nsXULElement.cpp, line 2676] nsXULCommandDispatcher::UpdateCommands [d:\builds\seamonkey\mozilla\rdf\content\src\nsXULCommandDispatcher.cpp, line 293] XULCommandDispatcherUpdateCommands [d:\builds\seamonkey\mozilla\rdf\content\src\nsJSXULCommandDispatcher.cpp, line 387] js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 666] js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2227] js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 686] js_InternalCall [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 759] JS_CallFunctionValue [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 2754] nsJSContext::CallEventHandler [d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 564] nsJSEventListener::HandleEvent [d:\builds\seamonkey\mozilla\dom\src\events\nsJSEventListener.cpp, line 129] nsEventListenerManager::HandleEventSubType [d:\builds\seamonkey\mozilla\layout\events\src\nsEventListenerManager.cpp, line 639] nsEventListenerManager::HandleEvent [d:\builds\seamonkey\mozilla\layout\events\src\nsEventListenerManager.cpp, line 1137] nsXULElement::HandleDOMEvent [d:\builds\seamonkey\mozilla\rdf\content\src\nsXULElement.cpp, line 2676] nsXULTreeElement::FireOnSelectHandler [d:\builds\seamonkey\mozilla\rdf\content\src\nsXULTreeElement.cpp, line 380] nsXULTreeElement::SelectCell [d:\builds\seamonkey\mozilla\rdf\content\src\nsXULTreeElement.cpp, line 171] nsTreeFrame::SetSelection [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsTreeFrame.cpp, line 125] nsTreeCellFrame::HandleMouseDownEvent [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsTreeCellFrame.cpp, line 243] nsTreeCellFrame::HandleEvent [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsTreeCellFrame.cpp, line 196] PresShell::HandleEvent [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 2741] nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 841] nsViewManager::DispatchEvent [d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1678] HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 69] nsWindow::DispatchEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 425] nsWindow::DispatchWindowEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 442] nsWindow::DispatchMouseEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3335] ChildWindow::DispatchMouseEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3551] nsWindow::ProcessMessage [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 2646] nsWindow::WindowProc [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 609] USER32.dll + 0x124c (0x77e7124c) 0x00ba0176 jar - does this still occur for you?
I haven't seen this for a while now... so I'm content with works-for-me. Thanks, Jim
ok, mark wfm.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
verified
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.