Closed Bug 9365 Opened 26 years ago Closed 26 years ago

[PP] When a mail server icon is selected, Messenger crashes/quits

Categories

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

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: momoi, Assigned: waterson)

Details

(Whiteboard: Fixed by Bienvenu's patch?)

** Observed with 7/7/99 Win32 build ** 1. I start Messenger and see 3 mail server icons and 1 NNTP server icon. 2. The next thing I do is click once on one of the server icon in the left pane. This leads to a sudden quit. 3. I've found that if I double-click on the same server icon, it works without a crash and displays all the folders I have on the server. I have filed a few Talkback incident reports on this.
Heer's an URL to one of the reports I sent to Talkback: http://cyclone/reports/incidenttemplate.CFM?reportID=1099&style=0&tc=66&cp=3&ck1 =SUser+email+address&cd1=momoi%40netscape%2Ecom&ck2=SBug+ID&cd2=isNotNull&bbid=1 0874493 Its Incident ID is: 10874493
For an easier access to the Talkback reports on this bug, you can go here and select the links to this bug number: http://cyclone/reports/reporttemplate.cfm?style=1&reportID=1099
QA Contact: lchiang → nbaca
Summary: When a mail server icon is selected, Messenger crashes/quits → [PP] When a mail server icon is selected, Messenger crashes/quits
nsSupportsArray::Clear [d:\builds\seamonkey\mozilla\xpcom\ds\nsSupportsArray.cpp, line 309] nsSupportsArray::DeleteArray [d:\builds\seamonkey\mozilla\xpcom\ds\nsSupportsArray.cpp, line 58] nsSupportsArray::`scalar deleting destructor' nsSupportsArray::Release [d:\builds\seamonkey\mozilla\xpcom\ds\nsSupportsArray.cpp, line 53] StyleContextImpl::~StyleContextImpl [d:\builds\seamonkey\mozilla\layout\base\src\nsStyleContext.cpp, line 1347] StyleContextImpl::`scalar deleting destructor' StyleContextImpl::Release [d:\builds\seamonkey\mozilla\layout\base\src\nsStyleContext.cpp, line 1413] nsCOMPtr_base::~nsCOMPtr_base [d:\builds\seamonkey\mozilla\xpcom\base\nsCOMPtr.cpp, line 26] nsCSSFrameConstructor::ConstructFrame [d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp, line 3885] nsCSSFrameConstructor::CreateTreeWidgetContent [d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp, line 6291] nsTreeRowGroupFrame::GetNextFrameForReflow [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsTreeRowGroupFrame.cpp, line 884] nsTableRowGroupFrame::ReflowMappedChildren [d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowGroupFrame.cpp, line 505] nsTableRowGroupFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowGroupFrame.cpp, line 1025] nsContainerFrame::ReflowChild [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 408] nsTableFrame::ReflowMappedChildren [d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableFrame.cpp, line 3820] nsTableFrame::ResizeReflowPass2 [d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableFrame.cpp, line 2892] nsTableFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableFrame.cpp, line 2592] nsTreeFrame::Reflow [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsTreeFrame.cpp, line 286] nsContainerFrame::ReflowChild [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 408] nsTableOuterFrame::IR_InnerTableReflow [d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableOuterFrame.cpp, line 567] nsTableOuterFrame::IR_TargetIsInnerTableFrame [d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableOuterFrame.cpp, line 357] nsTableOuterFrame::IR_TargetIsChild [d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableOuterFrame.cpp, line 347] nsTableOuterFrame::IncrementalReflow [d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableOuterFrame.cpp, line 313] nsTableOuterFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableOuterFrame.cpp, line 961] nsBlockReflowContext::ReflowBlock [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line 228] nsBlockFrame::ReflowBlockFrame [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2525] nsBlockFrame::ReflowLine [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2016] nsBlockFrame::ReflowDirtyLines [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 1825] nsBlockFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 1200] nsBoxFrame::FlowChildAt [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp, line 713] nsBoxFrame::FlowChildAt [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp, line 685] nsBoxFrame::FlowChildren [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp, line 412] nsBoxFrame::Reflow [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp, line 285] nsContainerFrame::ReflowChild [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 408] RootFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLFrame.cpp, line 245] nsContainerFrame::ReflowChild [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 408] ViewportFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsViewportFrame.cpp, line 440] nsHTMLReflowCommand::Dispatch [d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLReflowCommand.cpp, line 169] PresShell::ProcessReflowCommands [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 1323] PresShell::ExitReflowLock [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 702] PresShell::ContentInserted [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 1749] XULDocumentImpl::ContentInserted [d:\builds\seamonkey\mozilla\rdf\content\src\nsXULDocument.cpp, line 1949] RDFElementImpl::InsertChildAt [d:\builds\seamonkey\mozilla\rdf\content\src\nsRDFElement.cpp, line 1572] RDFGenericBuilderImpl::OnSetAttribute [d:\builds\seamonkey\mozilla\rdf\content\src\nsRDFGenericBuilder.cpp, line 1949] XULDocumentImpl::OnSetAttribute [d:\builds\seamonkey\mozilla\rdf\content\src\nsXULDocument.cpp, line 3734] RDFElementImpl::SetAttribute [d:\builds\seamonkey\mozilla\rdf\content\src\nsRDFElement.cpp, line 916] ElementSetAttribute [d:\builds\seamonkey\mozilla\dom\src\coreDOM\nsJSElement.cpp, line 265] js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 656] js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2218] js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 676] js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2218] js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 676] js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2218] js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 676] js_InternalCall [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 750] JS_CallFunctionValue [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 2645] nsJSEventListener::HandleEvent [d:\builds\seamonkey\mozilla\dom\src\events\nsJSEventListener.cpp, line 98] nsEventListenerManager::HandleEvent [d:\builds\seamonkey\mozilla\layout\events\src\nsEventListenerManager.cpp, line 590] RDFElementImpl::HandleDOMEvent [d:\builds\seamonkey\mozilla\rdf\content\src\nsRDFElement.cpp, line 2351] RDFElementImpl::HandleDOMEvent [d:\builds\seamonkey\mozilla\rdf\content\src\nsRDFElement.cpp, line 2356] RDFElementImpl::HandleDOMEvent [d:\builds\seamonkey\mozilla\rdf\content\src\nsRDFElement.cpp, line 2356] RDFElementImpl::HandleDOMEvent [d:\builds\seamonkey\mozilla\rdf\content\src\nsRDFElement.cpp, line 2356] RDFElementImpl::HandleDOMEvent [d:\builds\seamonkey\mozilla\rdf\content\src\nsRDFElement.cpp, line 2356] RDFElementImpl::HandleDOMEvent [d:\builds\seamonkey\mozilla\rdf\content\src\nsRDFElement.cpp, line 2356] Ninoschka - can you try this on the other platforms? Marking PP for now.
This looks like one of the stack traces in 9353. David B, did you ever open up a new bug or should this be it?
No, I didn't open a new bug. This stack trace looks a little bit more like the second crash I was seeing, but the user actions are more like the first crash. Let's leave this one open, but who should we assign it to? Obviously not Phil - perhaps someone in layout? Or hyatt?
Assignee: phil → hyatt
I'll start off by reassigning to hyatt since he's been taking table/tree related crashes that happen in our trees. David, if it's not yours please reassign to the layout team.
could this be a dup of 9354? I pulled after Troy's latest changes in layout\html\style and one of my crashes has gone away.
Build 1999070708M8: Win32/NT4 and Linux/Rehat 5.2 Note: Will try another Mac build since the latest one failed to start. I am not experiencing a crash when selecting the server icon once. I've tried configurations with 2 imap, 2 pop and 1 news server. It crashed one time on NT4 but I have been unable to reproduce.
It is true that the crash problem does not happen consistently. I have 4 server icons and I tried clicking on each one of them once. I carshed at the 4th one I tried. After that, it was easy to crash just by picking one server. I also bring up my Messenger directly via "apprunner -mail".
Have you rebuilt with Troy's change?
Build 1999070708M8: Mac 8.5.1 FYI: Unable to duplicate the crash by selecting the mail servers once. Tried a prefs50.js with 4 mail server, 1 news server. Also tried one with 3 mail servers and one news server.
1999070708M8: Win32/NT4, Linux/Redhat 5.2 I am able to duplicate a crash on NT4 and Linux with some regularity by single selecting the servers fairly quickly. It seems to crash when an IMAP server is selected (i.e. qatest22 and qatest33). I compared the TalkBack trace with the one included in this bug and they do not match. Should I log a separate bug?
http://bugzilla.mozilla.org/show_bug.cgi?id=9398 was just reported. Similar steps, but the platform is Linux. I cc'd hyatt on that bug. We'd really like this bug to be fixed for M8, if possible, since it's quite easy to run into this crash especially since our default prefs50.js shows a news and an IMAP server in the folder pane.
Status: NEW → ASSIGNED
Target Milestone: M8
Current status: I'm able to reproduce, and I've verified that this has nothing to do with any of my recent changes. The culprit therefore is something else that was checked in over the last few days. There are known problems with the tree widget and with Troy's recent checkin, so I'll start by resolving those and see if that gets rid of this bug.
This class of bugs is making it really hard to solve other bugs since I keep crashing while trying to work on them. If you could look into this for M8, I'd really appreciate this.
Priority: P3 → P1
setting p1
cc troy
Whiteboard: Fixed by Bienvenu's patch?
Assignee: hyatt → waterson
Status: ASSIGNED → NEW
Reassigning to self re: content model bustage.
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Fix checked in. Update mozilla/rdf/content/src/nsRDFTreeBuilder.cpp.
Status: RESOLVED → VERIFIED
OK using jul12 m8 build on NT 4.0. Haven't seen any problem with other platforms either with the jul12 builds.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.