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)
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.
Assignee | ||
Comment 1•25 years ago
|
||
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...
Assignee | ||
Comment 2•25 years ago
|
||
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
Comment 3•25 years ago
|
||
Is it a stack overflow?
Assignee | ||
Comment 4•25 years ago
|
||
It's a stack crawl, last caller at the bottom.
Comment 5•25 years ago
|
||
Thanks, I got that part. :-)
What I was wondering is, are we running out of memory because we are
overflowing the stack?
Assignee | ||
Comment 6•25 years ago
|
||
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.
Reporter | ||
Comment 7•25 years ago
|
||
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?
Assignee | ||
Comment 8•25 years ago
|
||
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 | ||
Updated•25 years ago
|
Assignee: putterman → ducarroz
Assignee | ||
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 9•25 years ago
|
||
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.
Comment 10•25 years ago
|
||
Mac (1999-09-15-08 M11)
POP/IMAP/News: Mail folders show up on Mac .
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•