(From update of attachment 435225)
Although this obviously avoids removing the wrong folder, it doesn't actually stop multiple attempts to check for status, and in fact would make it harder to retrofit such a check.
>+ // if we get an error running the url, it's better
>+ // not to chain the next url.
>+ if (NS_FAILED(exitCode))
>+ break;
What about the remaining folders?
>+ nsCOMPtr<nsIMsgImapMailFolder> folder = m_foldersToStat[folderCount - 1];
>+ m_foldersToStat.RemoveObjectAt(folderCount - 1);
>+ folder->UpdateStatus(this, nsnull);
Is UpdateStatus not always async?
>- if (imapFolder && !isServer)
>+ if (imapFolder && !isServer &&
>+ m_foldersToStat.IndexOfObject(imapFolder) == -1)
Nit: IndexOfObject is really slow because it QIs the argument and each member to nsISupports first. If you don't need that just use IndexOf instead.
(From update of attachment 435225)
Although this obviously avoids removing the wrong folder, it doesn't actually stop multiple attempts to check for status, and in fact would make it harder to retrofit such a check.
>+ // if we get an error running the url, it's better exitCode) )
>+ // not to chain the next url.
>+ if (NS_FAILED(
>+ break;
What about the remaining folders?
>+ nsCOMPtr< nsIMsgImapMailF older> folder = m_foldersToStat [folderCount - 1]; .RemoveObjectAt (folderCount - 1); >UpdateStatus( this, nsnull);
>+ m_foldersToStat
>+ folder-
Is UpdateStatus not always async?
>- if (imapFolder && !isServer) .IndexOfObject( imapFolder) == -1)
>+ if (imapFolder && !isServer &&
>+ m_foldersToStat
Nit: IndexOfObject is really slow because it QIs the argument and each member to nsISupports first. If you don't need that just use IndexOf instead.