Closed Bug 809990 Opened 12 years ago Closed 11 years ago

Don't set the offline folder flag for SPAM and TRASH folders

Categories

(MailNews Core :: Networking: IMAP, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 22.0

People

(Reporter: rkent, Assigned: mkmelin)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

In setting up an initial Gmail account, both the SPAM and TRASH folders have the "use offline" flag set. We should not be downloading messages by default for these folders. The "use offline" should match whatever the gloda defaults are for which folders to index.
OS: Windows 7 → All
Hardware: x86_64 → All
Assignee: nobody → mkmelin+mozilla
Attachment #706857 - Flags: review?(mozilla)
Attachment #706857 - Flags: review?(mozilla) → review?(irving)
Comment on attachment 706857 [details] [diff] [review]
proposed fix

Review of attachment 706857 [details] [diff] [review]:
-----------------------------------------------------------------

I'm OK with this being checked in with the comments fixed; if you decide to change the NS_ENSURE_SUCCESS please send it back to me for a quick re-review.

::: mailnews/imap/src/nsImapMailFolder.cpp
@@ +968,5 @@
> +      // not always the case.
> +      uint32_t flags = 0;
> +      child->GetFlags(&flags);
> +
> +      // Make the newly created folder is flagged for offline use if the

Wording:

// Set the offline use flag for the newly created folder if the

@@ +969,5 @@
> +      uint32_t flags = 0;
> +      child->GetFlags(&flags);
> +
> +      // Make the newly created folder is flagged for offline use if the
> +      // offline_download prefis true, unless it's the Trash or Junk folder.

prefis -> preference is

@@ +974,5 @@
> +      if (!(flags & (nsMsgFolderFlags::Trash | nsMsgFolderFlags::Junk)))
> +      {
> +        nsCOMPtr<nsIImapIncomingServer> imapServer;
> +        rv = GetImapIncomingServer(getter_AddRefs(imapServer));
> +        NS_ENSURE_SUCCESS(rv, rv);

Do we really want to return early if this fails, or do we just want to give up on setting the flag but continue with the rest of the method?
Attachment #706857 - Flags: review?(irving) → review+
(In reply to Irving Reid (:irving) from comment #2)
> Do we really want to return early if this fails, or do we just want to give
> up on setting the flag but continue with the rest of the method?

A failure would be pretty strange, especially given that the same thing is used in AddSubfolderWithPath which is called a few lines earlier, and that method is required to succeed to hit the code i'm adding. So I think I prefer the patch as is, with NS_ENSURE_SUCCESS(rv, rv);
http://hg.mozilla.org/comm-central/rev/e115168a56b6 -> FIXED
Status: NEW → RESOLVED
Closed: 11 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 22.0
You need to log in before you can comment on or make changes to this bug.