To reproduce: 1) Set a pop3 account, do not have automatic download on biff . 2) Have some messages in your inbox already present. 3) Start up, allow the inbox to be loaded so that summary is valid 4) Now select the root/ acct level folder 5) Make sure you have some messages to download 6) Do a get msg() 7) Allow new mail to come to inbox 8) Now select inbox - causes hang. I have seen this happen on 12/10 build but not on 12/7 build and it is due to your speeding up parsing of local folders. The reason it hangs is because folder loaded notification is never sent. There is no question of parsingInbox coming into picture because summary is valid when you have loaded the inbox, then you go on and select root folder/ acct folder.....
accepting - I wonder why we're not sending a folder loaded notification. Do you know, or do you just know that we're not sending one? We should always send one...Is mozilla really hanging, or are we just displaying a stop watch and the mozilla is alive and other folders can be selected, browser started up, etc?
Status: NEW → ASSIGNED
oh dear, this worked fine for me. You're 100% sure this isn't because of some change in your tree? You recreated this on a release build?
yes, i downloaded builds from sweetlou. The reason is because summary is set to invalid when you go back and select inbox after selecting root folder and downloading mail to inbox.
ah, now, I see something similar to that. Apparently, get new mail is not leaving the summary file in a valid state, which might explain all that reparsing that people have been seeing. But mozilla doesn't hang, and I can read messages, etc.
I think, in this case, we need to kick off a reparse of the db, right? And we need to fix get new mail so that it keeps the db valid.
or are we just displaying a stop watch? we are displaying that stop-watch - hang for me, even selecting other folders and coming back to inbox - still stop watch is being displayed, the db thinks summary is not valid therefore folderLoaded notification never gets sent from c++ to js. ya, i am able to do things in mozilla like read message etc
well, duh, we can't kick off reparsing because we might be reparsing. Hmm, well, we need to make sure we don't invalidate summary files during a session.
Summary: Regression: Selecting pop3 inbox hangs → Regression: Selecting pop3 inbox leaves stopwatch cursor
OK, the problem is that the pop3 download code is setting the time stamp and folder size of the inbox *before* closing the inbox file, so it's not valid. I think this is probably the number one cause of out of date inbox summary files.
ok, closing inboxOutputStream and then calling onStopRequest on parser does fix the problem.
I considered that approach but rejected it - I'm not sure that we will always flush out the last line to the file if we do it that way. I've just added the following lines after we close the output stream: // tell the parser to mark the db valid *after* closing the mailbox. if (m_newMailParser) m_newMailParser->UpdateDBFolderInfo();
::OnStopRequest calls DoneParsingFolder, which flushes the last line, so I didn't want to close the stream before calling OnStopRequest.
Created attachment 61162 [details] [diff] [review] proposed fix as described in the comment. Also, changed a NULL to nsnull. seeking reviews.
Comment on attachment 61162 [details] [diff] [review] proposed fix sr=sspitzer
Attachment #61162 - Flags: superreview+
r=naving, we are now marking summary valid to true twice but i don't see how we can avoid that.
yes, you're right, we do - I looked for a way to not do that, but I couldn't figure out an easy way either.
fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
verified no more hang while get message with auto download biff is turned off on an existing profile. builds: 2002-01-03-06 win98, linux rh 6.2, mac os x
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.