51540 - can't retrieve POP mail on Mac not prompted for password

Status: VERIFIED FIXED

(MailNews Core :: Networking: POP, defect, P3)

Description

[Asa Dotzler [:asa]]

When I set up a new POP mail account on a new mozilla install with new profile
the list of folders under the server is in the incorrect order and selecting
Inbox and hitting Get Msg does nothing.

Steps:
1. install 090604 mac mozilla build (both Installer and sea.bin)
2. launch messenger bydragging its icon onto the mozilla icon
3. set up new POP mail account
4. expand server folder to reveal Drafts, Inbox, Sent, Template, and Trash folders
5. select Inbox and click the Get Msg button inthe toolbar

Results: button depresses but nothing happens.
Expected Results: user should be prompted for password and mail should be
downloaded.

Additional Comments:  The Inbox folder appears below the Drafts folder.  I've
also experienced difficulty with setting up a new POP acct on win32 with an old
profile with modern skin but that is probably unrelated (I was able to set up
POP on today's win32 with new or old profile in classic skin)

Comment 1

[Asa Dotzler [:asa]]

adding keyword smoketest.

Comment 2

[David :Bienvenu]

sounds like the inbox flag is not getting set. Probably all my fault since I
made some fixes to the flag handling so that we wouldn't open all the special
db's at start-up, but I haven't seen this. Does it work after you shutdown and
restart? I also don't see why it would be mac-specific.

Comment 3

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

on my fresh mac mozilla build,
I was just able to create a new pop account and get new mail.
I'll try to exit, and restart and see if I can still get new mail.

Comment 4

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

when I restart, I'm able to get new pop mail.

note, in my folder pane, inbox is the top folder and has the special "inbox"
folder icon.

I'll go try the 090604 official build (from sea.bin) and see if I can reproduce
the problem.

Comment 5

[Chris McAfee]

pop worksforme on linux, if that helps.

Comment 6

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

the mozilla mac (sea.bin) 090604 build (from sweetlou) works for me.

Comment 7

[Daniel (Leaf) Nunes]

this is highly disruptive; what skin are you using, seth? new profiles every
time? How about pre-existing profiles?

Comment 8

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

I'm using new profiles every time, and the classic skin.

leaf tells me pchen is able to reproduce this.  I'll go stop by his cube.

Comment 9

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

over paul's shoulder, I saw the problem.

laurel is also able to reproduce the problem, and she's trying to help me now.

Comment 10

[Scott MacGregor]

Should we back out the flag changing stuff so we can open the tree? Or should
this be taken off the smoketest blocker list and left as a dogfood P1 bug? Since
it is only on the Mac and doesn't appear to be effecting all mac users, I wonder
if we can take it off the smoketest list and give us a day to work it out?

Comment 11

[jefft]

Seth, thanks much for looking into the problem. I don't have a Mac at home. Let 
me know if there is any way I can reproduce it from a Win32 or Linux box. 
Thanks,

Comment 12

[Scott MacGregor]

I'm in favor of the second plan which is put it on the dogfood list and we'll
tackle it today but go ahead and open the tree. 

Comment 13

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

ok, I've seen this once now on the mac bits from sweetlou.  
I'm a choad, my build was not fresh.

my guess would be the folder flag stuff that bienvenu mentioned, except that it
doesn't happen on all plaftorms.

re-assign to me since jefft is mac-less.

I'll start debugging after some food.

Comment 14

[Daniel (Leaf) Nunes]

ok, i'll reopen the tree then, per mscott's comments.

Comment 15

[David :Bienvenu]

the flag changes happened over the weekend, so if they're the problem, Tuesday's
build would have the same problem. Does it?

Comment 16

[David :Bienvenu]

adding self to cc list.

Comment 17

[leger]

Putting on [dogfood+] radar.

Comment 18

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

updating keywords and whiteboard so it shows up on the right queries.

I can reproduce this bug.  checking to see if restarting the app fixes the
problem.  

Comment 19

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

note: quiting and restarting the app makes the problem go away.

Comment 20

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

did some debugging with bienvenu last night.  I'll continue to work on this
today.

Comment 21

[David :Bienvenu]

clearing dogfood since the workaround is to restart, and after that, it works 
fine.

Comment 22

[David :Bienvenu]

One possibility is that we create the INBOX.msf file *after* we've set the flag 
on the folder, and the newly created database doesn't have the flags set 
correctly. I remember this being a problem in the past, but I don't know how 
Jeff worked around it.

Comment 23

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

from debugging, it looks like david is right on the money.

we set the flag on the inbox correctly, but then later when we open up the
account in the folder pane, here's what happens:

...
GetTarget()
...
GetSubFolders()
UpdateSummaryTotals()
ReadDBFolderInfo()
ReadFolderFromCacheElem()

ReadFolderFromCacheElem() will override mFlags from 4100 to 1028.

line 799 of nsMsgDBFolder.cpp:

	element->GetInt32Property("flags", (PRInt32 *) &mFlags);

Comment 24

[David :Bienvenu]

I wonder why this doesn't happen on Windows or Linux. I'm not sure who causes
the db to get created. You could try setting a breakpoint on the code that
creates a local .msf file, which should be around line 74 of nsMailDatabase.cpp:

	if (!summarySpec.Exists() && create)
		newFile = PR_TRUE;

Comment 25

[David :Bienvenu]

OK, here's how Jeff fixed this before. In nsMsgLocalMailFolder::GetDatabase(),
the following code tries to make sure the flags in the folder get echoed to the db.

            if (folderOpen == NS_MSG_ERROR_FOLDER_SUMMARY_MISSING)
                dbFolderInfo->SetFlags(mFlags);
            dbFolderInfo->GetTransferInfo(getter_AddRefs(transferInfo));

So, that should be OK. The question, I guess, is how come the folder cache elem
is wrong.  And why is there a folder cache elem in the first place since there
wasn't a folder cache at startup? We must have created the elem and not set its
flags correctly.  

Comment 26

[Jim Roskind]

Pop mail is the most common form of mail... and many in-house users rely on it.
Marking dogfood-plus.

Comment 27

[David :Bienvenu]

taking away dogfood+. Do many in-house users create a new profile every day?

Comment 28

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

fix in hand.  getting it reviewed by the almighty bienvenu now.

Comment 29

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

fixed.

the key we pass to the folder cache is the persistent file
descriptor string for the db file for the folder.  in some cases, the db file
doesn't exist.  when we get the persistent descriptor string on win32 and linux,
this string was null.  on the mac, bless its little heart, this was "".  so we
were writing and reading to the same cache element for all the folders, since we
were using "" as the key. 

I fixed the folder cache code to treat a "" key as an error.

Comment 30

[laurel]

OK for both migrated POP and new POP profiles using 2000-09-08-20 commercial m18
build.