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

VERIFIED FIXED in M18

Status

P3
blocker
VERIFIED FIXED
18 years ago
10 years ago

People

(Reporter: asa, Assigned: sspitzer)

Tracking

Trunk
PowerPC
Mac System 9.x

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3+] working on this (9-7-00))

(Reporter)

Description

18 years ago
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)
(Reporter)

Comment 1

18 years ago
adding keyword smoketest.
Keywords: smoketest

Comment 2

18 years ago
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.
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.
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

18 years ago
pop worksforme on linux, if that helps.
the mozilla mac (sea.bin) 090604 build (from sweetlou) works for me.

Comment 7

18 years ago
this is highly disruptive; what skin are you using, seth? new profiles every
time? How about pre-existing profiles?
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.
over paul's shoulder, I saw the problem.

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

Updated

18 years ago
QA Contact: lchiang → laurel

Comment 10

18 years ago
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

18 years ago
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

18 years ago
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. 
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.
Assignee: jefft → sspitzer

Comment 14

18 years ago
ok, i'll reopen the tree then, per mscott's comments.
Keywords: smoketest → dogfood

Comment 15

18 years ago
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

18 years ago
adding self to cc list.

Comment 17

18 years ago
Putting on [dogfood+] radar.
Whiteboard: [dogfood+]

Updated

18 years ago
Target Milestone: --- → M18
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.  
Status: NEW → ASSIGNED
Keywords: nsbeta3
Whiteboard: [dogfood+] → [dogfood+],nsbeta3+
note: quiting and restarting the app makes the problem go away.

Updated

18 years ago
Whiteboard: [dogfood+],nsbeta3+ → [dogfood+][nsbeta3+]
did some debugging with bienvenu last night.  I'll continue to work on this
today.
Whiteboard: [dogfood+][nsbeta3+] → [dogfood+][nsbeta3+] working on this (9-7-00)

Comment 21

18 years ago
clearing dogfood since the workaround is to restart, and after that, it works 
fine.
Whiteboard: [dogfood+][nsbeta3+] working on this (9-7-00) → [nsbeta3+] working on this (9-7-00)

Comment 22

18 years ago
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.
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

18 years ago
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

18 years ago
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

18 years ago
Pop mail is the most common form of mail... and many in-house users rely on it.
Marking dogfood-plus.
Whiteboard: [nsbeta3+] working on this (9-7-00) → [dogfood+][nsbeta3+] working on this (9-7-00)

Comment 27

18 years ago
taking away dogfood+. Do many in-house users create a new profile every day?
Whiteboard: [dogfood+][nsbeta3+] working on this (9-7-00) → [nsbeta3+] working on this (9-7-00)
fix in hand.  getting it reviewed by the almighty bienvenu now.
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.

Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 30

18 years ago
OK for both migrated POP and new POP profiles using 2000-09-08-20 commercial m18
build.
Status: RESOLVED → VERIFIED
Product: MailNews → Core

Updated

14 years ago
OS: Mac System 9.x
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.