Closed Bug 13778 Opened 25 years ago Closed 25 years ago

mail folders aren't showing up on mac

Categories

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

PowerPC
Mac System 8.6
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: scottputterman, Assigned: bugzilla)

Details

Currently accounts show up in the mailnews 3pane on the mac, but you can't open them to get folders. I thought this might be related to some other problems we saw in RDF, but backing out that code didn't make any difference. Any mac debugging help you can off jean-francois would be appreciated.
I can reproduce the problem with a build from yesterday morning. I get some mork asserst message when I try to expand my pop3 account icon. I am still looking at it...
Apparently, something goes wrong during the initialization of messenger. The creation of the folder failed with a out of memory error. Still investigating... 048EEA00 PPC 1743A7EC js_Invoke+0090C 048EE900 PPC 1731920C ElementSetAttribute(JSContext*, JSObject*, unsigned int, long*, long*)+002D4 048EE7C0 PPC 15FB244C RDFElementImpl::SetAttribute(const nsString&, const nsString&)+000B4 048EE760 PPC 15FB7D28 RDFElementImpl::SetAttribute(int, nsIAtom*, const nsString&, int)+00F3C 048EE4D0 PPC 15F9CF58 XULDocumentImpl::AttributeChanged(nsIContent*, nsIAtom*, int)+00238 048EE350 PPC 15FA8824 XULDocumentImpl::RebuildWidgetItem(nsIContent*)+002A4 048EE240 PPC 15FCFD6C RDFGenericBuilderImpl::RebuildContainer(nsIContent*)+00184 048EE150 PPC 15FCEF48 RDFGenericBuilderImpl::CreateContents(nsIContent*)+000D4 048EE080 PPC 15FD8F10 RDFGenericBuilderImpl::CreateContainerContents(nsIContent*, nsIRDFResource*, int)+ 008A0 048EDEC0 PPC 15FD7664 RDFGenericBuilderImpl::CreateWidgetItem(nsIContent*, nsIRDFResource*, nsIRDFResource*, int, int)+00064 048EDE50 PPC 15FD450C RDFGenericBuilderImpl::FindTemplate(nsIContent*, nsIRDFResource*, nsIRDFResource* , nsIContent**)+00704 048EDD60 PPC 15FD3888 RDFGenericBuilderImpl::IsTemplateRuleMatch(nsIContent*, nsIRDFResource*, nsIRDFResource*, nsIContent*, int*)+00444 048EDBE0 PPC 15FDA780 RDFGenericBuilderImpl::IsEmpty(nsIContent*, nsIRDFResource*)+00368 048EDB20 PPC 15F7A5C4 CompositeDataSourceImpl::GetTarget(nsIRDFResource*, nsIRDFResource*, int, nsIRDFNode**)+00100 048EDAC0 PPC 16B5B230 nsMsgFolderDataSource::GetTarget(nsIRDFResource*, nsIRDFResource*, int, nsIRDFNode**)+00098 048EDA60 PPC 16B5E414 nsMsgFolderDataSource::createFolderNode(nsIMsgFolder*, nsIRDFResource*, nsIRDFNode**)+001D8 048EDA10 PPC 16B5F430 nsMsgFolderDataSource::createFolderChildNode(nsIMsgFolder*, nsIRDFNode**)+00050 048ED990 PPC 168C95FC nsMsgLocalMailFolder::GetSubFolders(nsIEnumerator**)+0018C 048ED4B0 PPC 168C9344 nsMsgLocalMailFolder::AddDirectorySeparator(nsFileSpec&)+0006C 048ED2F0 PPC 17511A2C nsFilePath::nsFilePath(const nsFileSpec&)+00038 048ED2B0 PPC 17511B34 nsFilePath::operator=(const nsFileSpec&)+00028 048ED260 PPC 1750FCA8 MacFileHelpers::PathNameFromFSSpec(const FSSpec&, unsigned char)+00394 048ED110 PPC 174D5E9C nsDebug::Assertion(const char*, const char*, const char*, int)+00040
Is it a stack overflow?
It's a stack crawl, last caller at the bottom.
Thanks, I got that part. :-) What I was wondering is, are we running out of memory because we are overflowing the stack?
I add to stop debugging because my soucres wasn't in sync with the binary. I am currently rebuilding my whole tree. I have the feeling that the error message is bogus, the memory should be fine at this point. I will investigate more as soon my build is done.
From stepping through it, I'm finding that it doesn't think my mail directory is a directory and therefore it doesn't create any children. I wonder if someone changed the mac version of nsFileSpec and broke it?
Ok, I found the problem. What appends is that know we use GetFilePrefs to retreive the directory for the mailbox. But on Mac, GetFilePrefs expect a mac file spec encode in binex as input. Therefore as the directory prefes is written in plain ascii, it fail. I have extended the function nsMsgIncomingServer::GetFileValue to be able to read from a plain ascii patch if needed. nsresult nsMsgIncomingServer::GetFileValue(const char* prefname, nsIFileSpec **spec) { char *fullPrefName = getPrefName(m_serverKey, prefname); nsresult rv = m_prefs->GetFilePref(fullPrefName, spec); PRBool valid = PR_FALSE; if (NS_SUCCEEDED(rv)) { (*spec)->IsValid(&valid); if (! valid) { /* Something went wrong. Maybe because we are on Mac and the path is in plain ascii */ char *val = nsnull; rv = m_prefs->CopyCharPref(fullPrefName, &val); if (NS_SUCCEEDED(rv)) { (*spec)->SetNativePath(val); PR_Free(val); } } } PR_Free(fullPrefName); return rv; }
Assignee: putterman → ducarroz
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
I have finally change nsPref::GetFilePref instance just fixing the problem for mailnews (I would had to change it a two different locations inside mailnews itself). modules affected: POP3/IMAP/News, Pref Window. Fixed and checked in.
Status: RESOLVED → VERIFIED
Mac (1999-09-15-08 M11) POP/IMAP/News: Mail folders show up on Mac .
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.