562767 - When sending Mail with attachment via GMail's Web Interface, TB shows that message in SENT and TRASH (in TRASH with subject "Attachment")

Status: RESOLVED INVALID

(Thunderbird :: General, defect)

Description

[dfghjkjhg]

User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b2pre Thunderbird/3.0.4

When Sending a mail with an attachment directly via GMail's Web Interface, TB shows that message in SENT and TRASH (in Trash with subject "Attachment").
But TRASH doesn't make sense. Shouldn't appear in TRASH at all.

GMail's Web Interface itself doesn't show that message a second time in TRASH with subject "Attachment".

REMARK: I use GMail in TB via IMAP.

Reproducible: Always

Comment 1

[dfghjkjhg]

Amendment:
Tested the other way round:

When sending a mail with attachment via TB, then it's only saved to TB's SENT folder (and thus synced to GMail's SENT).
It's not saved to TB's TRASH (and thus also not synced to GMail's TRASH).

Comment 2

[WADA:World Anti-bad-Duping Agency]

Whhat *IMAP folder* presented to Tb by Gmail IMAP do you mean by Gmail's SENT/Tb's SENT or Gmail's TRASH/Tb's TRASH? Next?
 [Gmail]/Sent Mail ("Sent Mail" under "[Gmail]", Gmail's folder name=Sent Mail)
 [Gmail]/Trash     ("Trash"     under "[Gmail]", Gmail's folder name=Trash)
If you are talking about above Gmail's standard folders, I could observe phenomenon.
(1) At Gmail's Web Interface, compose a mail with rich text format(HTML).
(2-1) Attach file-1 to the mail. Wait for end of uploading.
(2-2) Check mails in [Gmail]/Trash folder by Tb via Gmail IMAP.
      (click other folder, then click [Gmail]/Trash again) 
   => Plain text mail of Subject=Attachment with file-1 attached
      is generated in [Gmail]/Trash by Gmail.
(3-1) Attach file-2 to the mail. Wait for end of uploading.
(3-2) Check mails in [Gmail]/Trash folder by Tb via Gmail IMAP.
      (click other folder, then click [Gmail]/Trash again) 
   => Plain text mail of Subject=Attachment with file-2 attached
      is generated in [Gmail]/Trash by Gmail.
These work mails are not shown in "Trash" folder at Gmail Web Interface.
(4) If mail is sent at this step, these work mails still remain in [Gmail]/Trash.
(5) Empty Trash by Tb([Gmail]/Trash is used as trash folder of Tb).
    => Mails in [Gmail]/Trash disappear.
(6) Compact of [Gmail]/Trash by Tb.
    => "Compactng folder..." at status bar doesn't disappear.
    Response to expunge command is not returned from Gmail IMAP?
(7) Send mail.
    => Mail is normally sent.
    Delete of work mails by Tb doesn't interfere Gmail's mail sending.

Mail headers are as follows. As Received: header is seen in header, Gmail looks to utilize "mail sending path" to keep attached file data. And, as mail data is held in Trash([Gmail]/Trash via Gmail IMAP), Gmail looks to use Trash folder as work file for attachment data.

> MIME-Version: 1.0
> Received: by 10.220.111.71 with HTTP; Thu, 29 Apr 2010 17:53:52 -0700 (PDT)
> Date: Fri, 30 Apr 2010 09:53:52 +0900
> Message-ID: <[e-mail]>
> Subject: Attachment
> From: Yatter One <[e-mail]>
> Content-Type: multipart/mixed; boundary=0016e64ec9c4477c40048569ad71
>
> --0016e64ec9c4477c40048569ad71
> Content-Type: text/plain; charset=UTF-8
>
> --0016e64ec9c4477c40048569ad71
> Content-Type: text/html; charset=US-ASCII; name="sqlite.html"
> Content-Disposition: attachment; filename="sqlite.html"
> Content-Transfer-Encoding: base64
> X-Attachment-Id: f_g8maj6hk1
>(snip, base64 encoded data follows)

I believe Gmail's problem or Gmail IMAP problem, never Tb's bug. But confirming because phenomenon was observed and is reliably reproduced.

Comment 4

[dfghjkjhg]

Yes, my folder understanding/definitions are exactly as you described above ("Gmail standard folders").
Thanks for reproducing and describing your findings in order to make this bug description more precise.

Comment 5

[tonda kavalec]

The same problem without attachment and senting from SeaMonkey, not from the web

Comment 6

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #5)
> The same problem without attachment and senting from SeaMonkey, not from the web

Phenomenon explained by bug 562748 instead of this bug, isn't it?

Comment 7

[Wayne Mery (:wsmwk)]

(In reply to WADA from comment #2)
> I believe Gmail's problem or Gmail IMAP problem, never Tb's bug. But
> confirming because phenomenon was observed and is reliably reproduced.

Given that the phenomenon is caused by gmail, closing INVALID