The following test case also leads to a duplicated message in the Inbox. 1) In the account preferences set "To save disk space, do not download Messages larger than xx kB" 2) receive a message that's larger than xx 3) in the message pane, click on the link to download the rest of the truncated message The message is shown twice in the Inbox, with equal sizes. One message still shows the "truncated" message, while the second one is the completely downloaded message. version 3 alpha 1 (20060414), OS X Assigning to David per his request.

This issue seems to be familiar to me. In December 2003 I encountered the same kind of problem in the W2K version. See attached screen shot. Not sure though if it was solved.

Regression window: linux branch builds 2006-03-27 ok, 2006-03-28 broken http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=ThunderbirdTinderbox&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-03-27+03%3A00%3A00&maxdate=2006-03-28+06%3A00%3A00&cvsroot=%2Fcvsroot My guess would be fallout from bug 331159.

yes, bug 331159 is the cause of this. In some situations, that fix causes us to reload the just downloaded message, which interrupts the pop3 download, which causes nsMsgLocalMailFolder::OnStopRunningUrl to get called with an error status, which makes us not delete the original partial message. This happens when address book whitelisting is turned on - if we whitelist the message, we set the junk status to "good", just before the download is finished, which synchronously triggers the reload and the interrupt. The only fix I've come up with so far is not to send the junk status change notification when we're going from no score to "good", i.e., the message has just been classified. Since we treat no score and "good" as equivalent, this should be OK.

we treat no score and "good" equivalently, so don't send a notification.

Comment on attachment 224368 [details] [diff] [review] proposed fix sr=sspitzer, acting as super review for tbird while mscott is away.

or we can put back some of the code that broke this in 331159....the problem is that HandleJunkStatusChanged only knows about the folder and not the specific messages whose junk status has changed so we end up reloading the message when we don't want to.

Or, if the message display code kept track of the junk status of the current message, it could ignore the change notification if it was a change from "no status" to non junk, for example. Right now, it just gets a notification, but doesn't know what the previous status was.