244217 - Initial Mail retrieval from POP account fails(mac only)

Status: RESOLVED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[trix supremo]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040206 Firefox/0.8
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040206 Firefox/0.8

Unable to retrieve mail after creating new POP email account.



Reproducible: Always
Steps to Reproduce:
1. Remove Profiles directory: HD:Users:[Uname]:Library:Mozilla
2. Bypass initial reg setup.
3. Setup Email (POP)Account.
4. Attempt to download messages.
Actual Results:  
No response

Expected Results:  
Should allow you to download messages.

Closing/reopening app corrects this problem and able to download messages. 
Works in Moz1.6 & Nscp7.1

Problem does occur on moz 1.7(20040518)

Comment 1

[(not reading, please use [e-mail] instead)]

confirm and accepting.

this affects trunk and 1.7

this is where we fail:

 if(NS_SUCCEEDED(rv) && rootFolder)
  {
    PRUint32 numFolders;
-->rv = rootFolder->GetFoldersWithFlag(MSG_FOLDER_FLAG_INBOX, 1, &numFolders,
getter_AddRefs(inbox));
  }
  nsCOMPtr<nsIMsgLocalMailFolder> localInbox = do_QueryInterface(inbox, &rv);

we fail to find the inbox folder.

I'll continue to debug later tonight.

Comment 2

[(not reading, please use [e-mail] instead)]

target for 1.7 final.

Comment 3

[(not reading, please use [e-mail] instead)]

I just noticed something interesting.

when I first start up, in my folder pane, my Inbox folder doesn't have the right
"special" icon, denoting it's an inbox.

I'll screen shot.

Comment 4

[(not reading, please use [e-mail] instead)]

Attachment: screen shot

Comment 5

[(not reading, please use [e-mail] instead)]

something is calling ClearFlag() on the inbox, and we are losing the
MSG_INBOX_FOLDER_FLAG, which explains the UI and the fact that
GetFoldersWithFlag() is failing.

Comment 6

[David :Bienvenu]

there was some code that attempted to set or clear the junk flag that might be
responsible...I reviewed a fix recently - though why this would be mac only I
don't know...

Comment 7

[(not reading, please use [e-mail] instead)]

actually, it doesn't look like ClearFlags() is the problem.  (it looks like we
are just clearing the has new mail flag)

we do appear to call SetFlag/SetFlags() on the inbox with the right flags, but
when debugging the inbox has flags of 5.  (instead of 1024 + 5).

maybe we have more than one inbox nsMsgDBFolder in memory?  (do you remember
weirdness like that before that confused the datasource)?

Comment 8

[(not reading, please use [e-mail] instead)]

debugging with david reveals what's going on.

the problem is here:

http://lxr.mozilla.org/mozilla/source/xpcom/obsolete/nsFileSpec.cpp#1229

because Inbox.msf doesn't exist, we fail silently.

#0  nsPersistentFileDescriptor::operator=(nsFileSpec const&) (this=0xbfff89f0,
inSpec=@0x11b7020c) at nsFileSpec.cpp:1230
#1  0x031994d8 in
nsPersistentFileDescriptor::nsPersistentFileDescriptor(nsFileSpec const&)
(this=0xbfff89f0, inSpec=@0x11b7020c) at nsFileSpec.cpp:1201
#2  0x03199470 in
nsPersistentFileDescriptor::nsPersistentFileDescriptor(nsFileSpec const&)
(this=0xbfff89f0, inSpec=@0x11b7020c) at nsFileSpec.cpp:1200
#3  0x0319e32c in nsFileSpecImpl::GetPersistentDescriptorString(char**)
(this=0x11b70200, aPersistentDescriptorString=0xbfff8b14) at nsFileSpecImpl.cpp:175
#4  0x103d88dc in nsMsgDBFolder::GetFolderCacheElemFromFileSpec(nsIFileSpec*,
nsIMsgFolderCacheElement**) (this=0x11b706a0, fileSpec=0x11b70200,
cacheElement=0xbfff8bb0) at nsMsgDBFolder.cpp:465
#5  0x103d8a74 in nsMsgDBFolder::ReadDBFolderInfo(int) (this=0x11b706a0,
force=0) at nsMsgDBFolder.cpp:491
#6  0x103db1cc in nsMsgDBFolder::GetFlags(unsigned*) (this=0x11b706a0,
_retval=0xbfff8cf0) at nsMsgDBFolder.cpp:1040
#7  0x23ce4154 in nsMsgLocalMailFolder::AddSubfolder(nsAutoString*,
nsIMsgFolder**) (this=0x11b6c300, name=0xbfff8f00, child=0xbfff8fa0) at
nsLocalMailFolder.cpp:306
#8  0x23ce38c8 in nsMsgLocalMailFolder::CreateSubFolders(nsFileSpec&)
(this=0x11b6c300, path=@0xbfff90b0) at nsLocalMailFolder.cpp:233
#9  0x23ce5488 in nsMsgLocalMailFolder::GetSubFolders(nsIEnumerator**)
(this=0x11b6c300, result=0xbfff91c0) at nsLocalMailFolder.cpp:529
#10 0x1e3c71ac in nsMsgFolderDataSource::createFolderChildNode(nsIMsgFolder*,
nsIRDFNode**) (this=0x119284d0, folder=0x11b6c328, target=0xbfff9460) at
nsMsgFolderDataSource.cpp:1959
#11 0x1e3c346c in nsMsgFolderDataSource::createFolderNode(nsIMsgFolder*,
nsIRDFResource*, nsIRDFNode**) (this=0x119284d0, folder=0x11b6c328,
property=0x112ad60, target=0xbfff9460) at nsMsgFolderDataSource.cpp:1051
#12 0x1e3c0124 in nsMsgFolderDataSource::GetTarget(nsIRDFResource*,
nsIRDFResource*, int, nsIRDFNode**) (this=0x119284d0, source=0x11b6c300,
property=0x112ad60, tv=1, target=0xbfff9460) at nsMsgFolderDataSource.cpp:380
#13 0x04fd0d80 in CompositeDataSourceImpl::GetTarget(nsIRDFResource*,
nsIRDFResource*, int, nsIRDFNode**) (this=0x10ce2350, aSource=0x11b6c300,
aProperty=0x112ad60, aTruthValue=1, aResult=0xbfff9460) at
nsCompositeDataSource.cpp:823
#14 0x12d848ec in
nsRDFConInstanceTestNode::FilterInstantiations(InstantiationSet&, void*) const
(this=0x11930650, aInstantiations=@0xbfff9520, aClosure=0xbfff9800) at
nsRDFConInstanceTestNode.cpp:176
#15 0x12d8d674 in TestNode::Propagate(InstantiationSet const&, void*)
(this=0x11930650, aInstantiations=@0xbfff95c0, aClosure=0xbfff9800) at
nsRuleNetwork.cpp:1045
#16 0x12d8d788 in TestNode::Propagate(InstantiationSet const&, void*)
(this=0x11930250, aInstantiations=@0xbfff9660, aClosure=0xbfff9800) at
nsRuleNetwork.cpp:1054
#17 0x12d8d788 in TestNode::Propagate(InstantiationSet const&, void*)
(this=0x1192fef0, aInstantiations=@0xbfff9780, aClosure=0xbfff9800) at
nsRuleNetwork.cpp:1054
#18 0x12daa1b0 in nsXULTemplateBuilder::Propagate(nsIRDFResource*,
nsIRDFResource*, nsIRDFNode*, nsClusterKeySet&) (this=0x2a72c00,
aSource=0xf9a12c0, aProperty=0x112ad60, aTarget=0x11b6c300,
aNewKeys=@0xbfff9800) at nsXULTemplateBuilder.cpp:422
#19 0x12daa524 in nsXULTemplateBuilder::OnAssert(nsIRDFDataSource*,
nsIRDFResource*, nsIRDFResource*, nsIRDFNode*) (this=0x2a72c00,
aDataSource=0x10ce2350, aSource=0xf9a12c0, aProperty=0x112ad60,
aTarget=0x11b6c300) at nsXULTemplateBuilder.cpp:493
#20 0x04fd3050 in CompositeDataSourceImpl::OnAssert(nsIRDFDataSource*,
nsIRDFResource*, nsIRDFResource*, nsIRDFNode*) (this=0x10ce2350,
aDataSource=0x11928060, aSource=0xf9a12c0, aProperty=0x112ad60,
aTarget=0x11b6c300) at nsCompositeDataSource.cpp:1462
#21 0x1e3bd1bc in nsMsgRDFDataSource::assertEnumFunc(nsISupports*, void*)
(aElement=0x10ce2354, aData=0xbfff99e0) at nsMsgRDFDataSource.cpp:404
#22 0x01bb957c in nsSupportsArray::EnumerateForwards(int (*)(nsISupports*,
void*), void*) (this=0x119280a0, aFunc=0x1e3bd150
<nsMsgRDFDataSource::assertEnumFunc(nsISupports*, void*)>, aData=0xbfff99e0) at
nsSupportsArray.cpp:627
#23 0x1e3bd0f4 in nsMsgRDFDataSource::NotifyObservers(nsIRDFResource*,
nsIRDFResource*, nsIRDFNode*, int, int) (this=0x11928060, subject=0xf9a12c0,
property=0x112ad60, object=0x11b6c300, assert=1, change=0) at
nsMsgRDFDataSource.cpp:391
#24 0x1e3cfb60 in
nsMsgAccountManagerDataSource::OnServerLoaded(nsIMsgIncomingServer*)
(this=0x11928060, aServer=0x11b6c1d0) at nsMsgAccountManagerDS.cpp:1276
#25 0x1e3b53dc in nsMsgAccountManager::NotifyServerLoaded(nsIMsgIncomingServer*)
(this=0xf99f650, server=0x11b6c1d0) at nsMsgAccountManager.cpp:1770
#26 0x1e3b9998 in nsMsgAccount::SetIncomingServer(nsIMsgIncomingServer*)
(this=0x11b6e0c0, aIncomingServer=0x11b6c1d0) at nsMsgAccount.cpp:191

http://developer.apple.com/documentation/Carbon/Reference/File_Manager/file_manager/ResultCodes.html#//apple_ref/doc/uid/TP30000107/RCM0037

-43 == File or directory not found; incomplete pathname

Comment 9

[(not reading, please use [e-mail] instead)]

I'm beginning to think the bug is that mac os x acts differently than win32 / linux.

see http://lxr.mozilla.org/mozilla/source/xpcom/obsolete/nsFileSpec.cpp#1230

mac will silently fail if the file does not exist.

I think the thing to do is check for fnfErr, and if we get that, create the file.

and I think I'll add an assert to this code so that problems like this will be
easier to catch later.

Comment 10

[(not reading, please use [e-mail] instead)]

Attachment: patch

a fix, suggested by david.

Comment 11

[(not reading, please use [e-mail] instead)]

Attachment: better patch, sorry about the confusion

Comment 12

[David :Bienvenu]

Comment on attachment 149162 [details] [diff] [review]
better patch, sorry about the confusion

back to my original suggestion :-)

Comment 13

[(not reading, please use [e-mail] instead)]

fixed on both trunk and branch.

I think we should assert in sPersistentFileDescriptor::operator= if we that code
silently fails on MacOS X.

I'll log a new bug on that.

Comment 14

[Brian Rogers]

This change is causing the contents of newsgroups and IMAP mail folders to be
redownloaded when opened. (on FreeBSD)
It seems to be truncating the msf files to zero bytes.

Comment 15

[(not reading, please use [e-mail] instead)]

> This change is causing the contents of newsgroups and IMAP mail folders to be
> redownloaded when opened. (on FreeBSD)
> It seems to be truncating the msf files to zero bytes.

yikes, I think I see that too on win32.

something is really wrong.  I'll back out my change.

Comment 16

[(not reading, please use [e-mail] instead)]

or, I'll fix my change to check if the .msf file exists before calling Touch().

[e-mail], thanks for catching the regression so quick.

Comment 17

[(not reading, please use [e-mail] instead)]

Attachment: supplimental fix for my bad regression

Comment 18

[(not reading, please use [e-mail] instead)]

ok, I've landed my supplimental fix.

Comment 19

[Scott MacGregor]

both patches fixed on the aviary 1.0 branch

Comment 20

[Scott MacGregor]

*** Bug 244575 has been marked as a duplicate of this bug. ***

Comment 21

[Frank Wein [:mcsmurf]]

*** Bug 244615 has been marked as a duplicate of this bug. ***

Comment 22

[Scott MacGregor]

*** Bug 244919 has been marked as a duplicate of this bug. ***

Comment 23

[(not reading, please use [e-mail] instead)]

*** Bug 245146 has been marked as a duplicate of this bug. ***

Comment 24

[Karen Huang]

Used latest Mozilla 1.7 06-15 nightly build on Mac:
Yes. This bug was fixed for initial mail retrieval from mail client itself.
But, if tried to initial mail from the browser (e.g Without setup mail yet,
tried to initial mail during "Send Link" or "Send Page" from the browser. Then I
am able to reproduce this problem described above....also I saw the
INBOX displays on the last from the folder pane.

Comment 25

[Karen Huang]

Reopening and removing "fixed1.7" for this bug based on above verification.

Comment 26

[(not reading, please use [e-mail] instead)]

now that david has a fix for bug #252843, this might be fixed.

Comment 27

[sairuh (rarely reading bugmail)]

vrfy'd fixed on aviary1.0 with tbird 2004112202-0.9 on mac os x 10.3.6.

Comment 28

[Mike Cowperthwaite]

Resetting to Fixed per comment 26-27.