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.