Closed Bug 439216 Opened 16 years ago Closed 16 years ago

When you copy a mail from "[Gmail]/Drafts" to "INBOX", it will be deleted (by GMail IMAP's special design)

Categories

(Thunderbird :: General, enhancement)

Product:
Thunderbird
Component:
General
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: helgehelge, Assigned: Bienvenu)

References

(Blocks 1 open bug)

Details

(Keywords: imap-interop) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14
Build Identifier: 3.0a1 (2008050715)

See reproduce steps

Reproducible: Always

Steps to Reproduce:
1. Set up an IMAP account at GMail
2. Compose a new mail without sending it.
3. Close it, click on "Save"
4. Move the mail (with the mouse) from the drafts folder to the INBOX folder

Actual Results:  
The mail was removed from "Drafts" but is NOT in the INBOX. You will find it in GMail Trash folder.

Expected Results:  
The mail should be in the INBOX
This is not a bug of Thunderbird.
This is a "bug" or feature of GMail:
When you copy a Draft in the inbox and delete the draft in "drafts" it will be also deleted in the inbox.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → INVALID
I reopened this: This behavior should be considered a bug of Thunderbird because David Ascher is considering better Google Mail IMAP support as a goal for Thunderbird 3 (https://wiki.mozilla.org/Thunderbird:Thunderbird3#Increased_Adoption ). Even if the main technical reason for this behavior may be on Google's side, it is important that we try to find a workaround to protect Thunderbird's users against this silent deletion of mails.

Because of silent deletion of data I set the severity to "critical".
Severity: normal → critical
Status: RESOLVED → UNCONFIRMED
Keywords: interop
OS: Windows XP → All
Hardware: PC → All
Resolution: INVALID → ---
Version: unspecified → Trunk
(In reply to comment #2)
> Even if the main technical reason for this behavior may be on Google's side,
> it is important that we try to find a workaround to protect Thunderbird's users
> against this silent deletion of mails.

I agree with you.

The "better Google Mail IMAP support as a goal for Thunderbird 3" pointed by following site is Bug 400931.
> https://wiki.mozilla.org/Thunderbird:Thunderbird3#Increased_Adoption
In the enhancement request, "silent deletion by Gmail & Gmail IMAP" is not considered to be very big issue for average users yet.

AFAIK, there are at least three kinds of "silent delete by Gmail IMAP".

(1) Copy/Move mail to [Gmail]/Trash folder of Gmail IMAP("Trash" folder of Gmail via Web/Gmail's label of "Trash").

All Gmail's label including "All Mail"("[Gmail]/All Mail" folder of Gmail IMAP) is removed from the single instance of the mail, which is logically held in "All Mail". And Gmail's label of "Trash" is added to the single instance of mail. And permanently removed from Gmail after 30 days.

(2) Copy/Move to a Gmail IMAP folder won't create new(larger) UID in target Gmail IMAP folder, if same mail already exists in the Gmail IMAP folder.

   1. Copy a mail to folder-A(say UID-A) and folder-B(UID-B, largest UID=UID-P)
   2. Move/Copy mail of UID-A to folder-B
   3. folder-A: copy uid UID-A folder-B. Gmail IMAP returns OK.
      Gmail adds Gmail's label of "folder-B" to the single instance of the mail,
      which is logically held in "All Mail".
   4. When move, Tb request to flag \Deleted for UID-A. Gmail IMAP returns OK.
      Gmail removes Gmail's label of "folder-A" from the single instance of the
      mail, which is logically held in "All Mail".
   5. FETCH folder-B => UID-B,...,UID-P only. Mail with UID greater than UID-P
      is not generated by Gmail IMAP, because UID-B for the mail already exists.
      It looks for users to be "loss of copied mail".
   6. FETCH folder-A => UID-A is already removed(same result as delete&expunge)

(3) Same phenomenon as (2) seems to occur when multiple copy of same mail from local mail folder. ("append" is used at above step 3.)
Google seems to execute duplicate mail check.

(2)&(3) is not real "data loss"("missing or hidden mail"), because the mail is held in at least "[Gmail]/All Mail" folder of Gmail IMAP, unless user intentionally deletes the mail from "[Gmail]/All Mail" folder. 
(1) is also "missing mail", not real "data loss", unless permanently removed from Gmail. But (1) can become real "data loss", if the mail will be permanently removed from Gmail after 30 days, and if user is convinced that the mail stays in "Trash" folder of Tb until user explicitly/implicitly requests delete/Expunge(Compact Folder).

Above "missing mail" or "data loss" is user's fault, because it's simply a result of that user doesn't care for Gmai/Gmail's desgin/spec.
However, if Bug 400931 will be fixed and released without care for "silent deletion by Gmail & Gmail IMAP", flood of unwanted bugs of "missing mail or data loss" with Gmail IMAP due to Tb's bug!!!" will probably occur.

By the way, "critical" is used for real Tb's bug(flaw in Tb's code, invalid design of Tb, etc.) only. In this bug's case, "Enhancement" should be used because here is bugzilla.mozilla.org.    
Thanks for info! Changed to "Enhancement".
Severity: critical → enhancement
(In reply to comment #3)
> (1) Copy/Move mail to [Gmail]/Trash folder of Gmail IMAP("Trash" folder of
> Gmail via Web/Gmail's label of "Trash").
> 
> All Gmail's label including "All Mail"("[Gmail]/All Mail" folder of Gmail IMAP)
> is removed from the single instance of the mail, which is logically held in
> "All Mail". And Gmail's label of "Trash" is added to the single instance of
> mail. And permanently removed from Gmail after 30 days.
When you delete a message in Gmail webmail, or copy it to [Gmail]/Trash through IMAP, its labels are retained in the Trash folder.  But, they do not appear in the corresponding IMAP folder, due to filtering on the back-end.  When you retrieve a message from the trash, it will re-appear in all of its folders.  OF course, if the initial action was "move", the original label is removed, and will only be restored by an explicit copy.
(Spam is similar.)
This does not affect the point, which is that the messages are automatically deleted after 30 days.  (That is not Gmail specific, but is true of many IMAP providers.  What is unique to Gmail is that the message is deleted from all "folders" when it is copied to trash.)

-------------------------------------------------------------
This bug report shows that we need to document the behaviour of the [Gmail]/Drafts folder.  When you COPY (or UID COPY) a message from the drafts folder in Gimap, the copy acts like a MOVE, and the message EXPUNGED from the drafts folder immediately.  Copying messages to the drafts folder works normally, leaving the other labels in place.

I cannot reproduce the reported behaviour, where the draft is deleted when moving it to the Inbox through Thunderbird.  There may be another variable, or the problem may have been fixed on the server.

(In reply to comment #5)
> This bug report shows that we need to document the behaviour of the
> [Gmail]/Drafts folder.  When you COPY (or UID COPY) a message from the drafts
> folder in Gimap, the copy acts like a MOVE, and the message EXPUNGED from the
> drafts folder immediately.

Brian Kennelly, thanks for explanation about 4-th "silent delete" case. 
It explained following new "silent delete" case.
 (1) Copy a mail to [Gmail]/Drafts folder of Gmail IMAP
 (2) Copy the mail in [Gmail]/Drafts to other mail folder such as "Label-A/X1",
     in which no mail eixts.
     ==> Mail in [Gmail]/Drafts disappears even though copy operation.

This is an IMAP problem, unless I am very well mistaken.
Component: General → Networking: News
Product: Thunderbird → Core
QA Contact: general → networking.news
IMAP, not NNTP...
Assignee: nobody → bienvenu
Component: Networking: News → Networking: IMAP
QA Contact: networking.news → networking.imap
(In reply to comment #0)
> Steps to Reproduce:
>(snip)
> 4. Move the mail (with the mouse) from the drafts folder to the INBOX folder
> Actual Results:  
> (A) The mail was removed from "Drafts" but is NOT in the INBOX.
> (B) You will find it in GMail Trash folder.

(A) is completely explained by Brian Kennelly, and I could reproduce it. But Brian and me can't reproduce (B).

To Helge(bug opener):
Was the mail really moved to Gmail's "Trash" by Gmail/Gmail IMAP?
(Gmail's folder/label of "Trash == Tb's [Gmail]/Trash folder via Gmail IMAP)

By the way, as bug opener says in Comment #2, this bug is not for problem in Tb's IMAP related code. This bug's purpose is ; To find way to reduce user's confusions which will surely be produced by Gmail IMAP's special design/spec.
For example, code improvement, good documentation.
Changing back to Product=Thunderbird/Component=General.
Component: Networking: IMAP → General
Product: Core → Thunderbird
(In reply to comment #9)
> (In reply to comment #0)
> > Steps to Reproduce:
> >(snip)
> > 4. Move the mail (with the mouse) from the drafts folder to the INBOX folder
> > Actual Results:  
> > (A) The mail was removed from "Drafts" but is NOT in the INBOX.
> > (B) You will find it in GMail Trash folder.
> 
> (A) is completely explained by Brian Kennelly, and I could reproduce it.

I did not reproduce it exactly as stated.  I can successfully move messages from [Gmail]/Drafts to Inbox.  What I found was that a copy from the drafts folder acts as a move.  Move works as expected.

Changing summary(move->copy), to avoid misleading.
Summary: When you move a mail in IMAP from "drafts" to "INBOX" it will be deleted (at least on GMail) → When you copy a mail from "[Gmail]/Drafts" to "INBOX", it will be deleted (by GMail IMAP's special design)
(In reply to comment #2)
> Even if the main technical reason for this behavior may be on Google's side,
> it is important that we try to find a workaround to protect Thunderbird's users
> against this silent deletion of mails.

To Helge:
This bug is better to be kept as report of the new(I called 4-th) "silent delete" case. So separate bug is required for "we try to find a workaround to protect Thunderbird's users against this silent deletion of mails".
Could you please open separate bug for "we try to find workaround..." to avoid confusion. (and close this bug as INVALID)
WADA, thanks for all your help!

I just tried to set up the new bug but now I realize that I am not sure how to do it correctly. Since this is supposed to reduce confusion I better ask:

Should this "we try to find a workaround to protect Thunderbird's users against silent deletion of mails" just be report of this specific bug or should it collect (as its title seems to be) all the "silent delete" cases?
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → INVALID
"Good documentation about silent delete of mail by Gmail IMAP" can be one of workarounds to protect users. So I think all "silent delete by Gmail IMAP" is better to be covered by single bug at first. However, detailed report of each "silent delete" case is not required in the bug, because it's already covered by some bugs and your this bug. See bugs listed in "dependency tree for Bug 402793" (with "Show Resolved") for "silent delete by Gmail IMAP" related phenomena or problems.
After you open bug, I'll add comment for types of "silent delete by Gmail"(shorter summary than my comment #3).

Okay, I opened this, I hope this works:
https://bugzilla.mozilla.org/show_bug.cgi?id=450227
You need to log in before you can comment on or make changes to this bug.