Deleting a Gmail Message Always Sends Item to [Gmail]/Trash

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5) Gecko/20091130 Thunderbird/3.0

Please note: this is *not* a duplicate of Bug 24064.

When accessing a Gmail account via IMAP, I'm unable to specify a custom trash folder. The default Gmail trash folder is AccountName\[Gmail]\Trash, but I would like to use something like AccountName\Trash. However, even after designating AccountName\Trash as the trash folder in Account Settings | Server Settings, when I delete a message it is moved to the AccountName\[Gmail]\Trash. There is also a strange behavior in that the trash icon is temporarily applied to the custom folder when initially opening the program, but then is applied to the AccountName\[Gmail]\Trash folder.

Reproducible: Always

Steps to Reproduce:
1. Setup a new Gmail account using IMAP.
2. Create a new folder in the root of the account. In other words, it should be at the same level as AccountName\Inbox -- e.g., AccountName\Trashcan.
3. In Tools | Account Settings | Server Settings change the drop-down selector for "When I delete a message: Move it to this folder:" to the folder you just created (AccountName\Trashcan).
4. Delete a message from the inbox.
Actual Results:
The deleted message is moved to the default Gmail trash folder (AccountName\[Gmail]\Trash).

Expected Results:
The deleted message should be moved to the custom folder (AccountName\Trashcan) instead.

One final oddity. If you close the program and run it again, watch the custom trash folder (AccountName\Trashcan) closely as the program opens. You will notice that the trash icon is applied to the custom folder initially, but after several seconds the icon is then applied to the default Gmail trash folder (AccountName\[Gmail]\Trash) folder.

One additional note: in prefs.js, the trash folder setting is correct:
   user_pref("mail.server.server2.trash_folder_name", "Trashcan");

In spite of the fact that this setting is correct, however, deleted messages are not moved to the custom folder when they're deleted.

Tested with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091130 Thunderbird/3.0 ID:20091130201643

I changed it to New and Account Manager

Created attachment 416328
Missing combo box

*** Bug 534197 has been marked as a duplicate of this bug. ***

Not specific to GMail as the title might imply. This bug is for IMAP in general (not sure about non-IMAP).

Also, platform independent (I am on openSUSE, 64bit).

*** Bug 509207 has been marked as a duplicate of this bug. ***

*** Bug 519387 has been marked as a duplicate of this bug. ***

Same issue effects all of the folder destination options (archive, etc). Can I bribe someone for a fix? lol

Wow, I didn't realize it was quite so severe. I'm very anxious for this fix as well, because it's a big enough problem that I can't move to TB3 until it's resolved. Hopefully some gracious coder will take care of it soon.

Same... blocking upgrade ability for me.

(In reply to comment #10)
> Wow, I didn't realize it was quite so severe. I'm very anxious for this fix as
> well, because it's a big enough problem that I can't move to TB3 until it's
> resolved.

Gmail/Gmail IMAP immediately removes mail in Gmail IMAP folder(Gmail Label) to which \Deleted flag is stored(auto-expunge=on is default of Gmai/Gmail IMAP), and Gmail IMAP doesn't support undelete for mail in Gmail IMAP folder(Gmail Label).
And, if you need to purge mail permanently, you have to move/copy mail to [Gmail]/Trash(Gmails automatically purges after 30 days). After move/copy to [Gmail]/Trash, if you want to immediately purge the mails permanently, you need to do "Shift+Delete at [Gmail]/Trash" or "Empty Trash at [Gmail]/Trash".

Because of above particularity of Gmail IMAP, our recommendation of IMAP delete model is "Remove immediately"(consistent with auto-expomge=on of Gmail/Gmail IMAP), and, in order to make "Empty Trash at [Gmail]/Trash" possible, [Gmail]/Trash is always used as trash folder currently.

Pleae note that root-level Trash of Tb corresponds to Gmail Label of [Imap]/Trash at Gmail Web Interface. So, if root-level Trash of Tb(==Gmail Label of [Imap]/Trash) is used as trash folder for Tb, "Empty Trash" merely removes Gmail Label of [Imap]/Trash. It'll easily produces confusion by many users.

(In reply to comment #5)
> Not specific to GMail as the title might imply. This bug is for IMAP in
> general (not sure about non-IMAP).
(In reply to comment #9)
> Same issue effects all of the folder destination options (archive, etc).

"one problem per a bug is rule at B.M.O", and this bug is for [Gmail]/Trash of Gmail IMAP.
Dave M, get IMAP log and check flow, and open separate bug with detailed description about your settings and/or environment(language pack, ...), with attaching log, please.

I took this bug to be about the fact that Thunderbird ignores its option to specify a trash destination. I had already created a bug which was dupe-closed ( https://bugzilla.mozilla.org/show_bug.cgi?id=534197 ).

The fact that this is "about GMail" is irrelevant, I think. Thunderbird has an option (in the UI even, you could do it in 2.x via prefs.js) to say, "Hey, when you delete a message, move it here:..." and ignores that option. It doesn't say, "Hey, this is GMail, lets ignore it." :-P

You have a recommendation, that's cool... but the options should still perform as they imply.

I appreciate all that the TB folks have done, but I am not interested in playing a game where I open bugs, have them closed, then get told to reopen them...

Thanks, take care.

(In reply to comment #13)
> I took this bug to be about the fact that Thunderbird ignores its option to
> specify a trash destination.

If Trash(Gmail Label of [Imap]/Trash) is selected as move to trash target folder, icon of Trash(Gmail label of [Imap]/Trash) is changed to trash icon(unable to rename/delete, ..., until it's removed from move to trash target.) And, [Gmail]/Trash(Gmail folder of "Trash" at Web) is always used by delete(when move to trash model), Empty Trash, ...
It's never simply "Tb ignores its option to specify a trash destination".

> The fact that this is "about GMail" is irrelevant, I think.

What you think is irrelevant to this bug, I think.
This bug is for fact that if Gmail IMAP(IMAP server provided by Gmail), "[Gmail]/Trash" is always used by delete(when move to trash model), Empty Trash, ..., regardless of "move to trash target folder" setting.
"[Gmail]/Trash" is Gmail IMAP only folder, isn't it?
Dave M, you said next in your dup'ed bug 534197, didn't you?
> both on GMail (one is plain GMail, the other is Google Apps).
Are you saying "Google Apps is different from Gmail, so 'about Gmail' is irrelevant"?

WADA,

Please read all of something and not just the parts you want. In the very second post to that bug I said:

"I setup a non-GMail related account and verified the issue there as well."

Sorry if that is unclear.

(In reply to comment #15)
> "I setup a non-GMail related account and verified the issue there as well."

Do you know if that account supports XLIST? I have a feeling that XLIST support in Thunderbird is causing this.

Just to try and be very extra clear.

Standard GMail accounts: Delete destination option is ignored.

Google Apps accounts: Delete destination option is ignored.

IMAP account that has nothing to do with Google or GMail: Delete destination
option is ignored.

Don't get me wrong, I am willing to do testing and provide info if I can. I am
not interested in playing a game with multiple bug reports due to an
unnecessarily narrow view of an issue.

(In reply to comment #16)
> (In reply to comment #15)
> > "I setup a non-GMail related account and verified the issue there as well."
>
> Do you know if that account supports XLIST? I have a feeling that XLIST support
> in Thunderbird is causing this.

I apologize... I am not sure. Is there a way for me to check this? If not, I will gladly call over to that servers admin in the morning.

It should be possible to turn on IMAP logs and check for an XLIST command, but I don't know the details, unfortunately.

(In reply to comment #15)
> In the very second post to that bug I said:
> "I setup a non-GMail related account and verified the issue there as well."

Oh sorry, I forgot to care for your bug 534197 comment #1.
Tb had problem like next.
  Change of "move to trash target folder" is not effective until restart.
Is it applicable to bug 534197 comment #1?

(In reply to comment #17)
> Standard GMail accounts: Delete destination option is ignored.
> Google Apps accounts: Delete destination option is ignored.
In both cases, [Gmail]/Trash is always used(this bug, and 90% of bug 534197).
> IMAP account that has nothing to do with Google or GMail: Delete destination
> option is ignored.
What IMAP folder is always used by Tb, even after setting change and restart of Tb? Inbox.Trash or Inbox/Trash?

(In reply to comment #19)
> It should be possible to turn on IMAP logs and check for an XLIST command, but
> I don't know the details, unfortunately.

No XLIST support according to email hosting company (although they stated quite honestly that they were not familiar with XLIST, so I am not sure).

(In reply to comment #20)
> Tb had problem like next.
> Change of "move to trash target folder" is not effective until restart.
> Is it applicable to bug 534197 comment #1?

No, the problem persists through restart.

> What IMAP folder is always used by Tb, even after setting change and restart
> of Tb? Inbox.Trash or Inbox/Trash?

I cannot do quite as much back and forth testing as I'd like right now (at work in the office) but after a quick test and looking at the log, it LOOKS like it is trying to use the folder wrong. It lists all my folders which are like:

INBOX.Archived (which is where I want trash to go)
INBOX.Saved
INBOX.Sent
etc etc

Then when I delete something it ends up being marked for deletion but still sits in the Inbox (invisible in TB, but on the server it is still in the Inbox). The log seems to imply (to my ignorant eyes) that it tries to do INBOX.INBOX.Archived then INBOX.INBOX/Archived. Neither of which exist.

However, an "Archived" folder is then created on the server as a sub of Inbox (I only see it on the server since I am not subscribed to it in TB) but the message is not moved to it.

Sorry, the above is unintentionally confusing. The folder hierarchy is that all folders are a sub of Inbox. What I meant about the newly (and wrongly) created folder is that it is a sub of a new sub Inbox. (Inbox>Inbox>Archived).

Hope that is more clear. Thanks.

(In reply to comment #21)
> INBOX.Archived (which is where I want trash to go)
> INBOX.Saved
> INBOX.Sent

It looks namespace=Inbox, delimiter=".".
See bug 480393, bug 491424, bug 532345.
See bug 479226 if Inbox.Trash and Trash has relation to your problem.

> The log seems to imply (to my ignorant eyes) that it tries to do
> INBOX.INBOX.Archived then INBOX.INBOX/Archived. Neither of which exist.

Already known phenomenon, when namespace="Inbox.", delimiter="." and folder path specification has "/" (subfolder). See bug 532345 comment #4.

(In reply to comment #17)
As all "Tb crash" is not always same problem even though "Tb crashes" is common, all phenomenon of "Delete destination option is ignored" for you is not always same issue/problem.

So I looked over those bugs and I am still a bit lost. How do I set a custom destination for deleted items if not via the UI? This bug or another, what info should I post where to help if there is no current resolution.

I'd love to move to TB3, but this functionality is important to me.

Thanks.

(In reply to comment #24)

To Dave M:

If problem of your comment #5(== your bug 534197 comment #1) is same issue as bug 480393/bug 491424/bug 532345(and DUP'ed bug to them) or bug 479226, and if you can't find workaround of your problem in any bugs reachable via those bugs, ask for workaround at one of most appropriate bug, please.
If you are not sure that your problem is dup of a bug, *READ* last paragrah of my comment #12, please.

Anyway, your problem of comment #5(== problem of your bug 534197 comment #1) is absolutely irrelevant to this bug for [Gmail]/Trash of Gmail IMAP. Dave M, please don't add comments for your irrelevant problem to this bug, in order to keep this bug readable. And, sorry for my lack of care for your bug 534197 comment #1 in bug 534197 which I duped to this bug.

I came to Bugzilla to report this exact bug. I keep going through the comments looking for a solution, but all I see are flames^H^H^H^H messages about what is or is not relevant about what one thinks.

I will try to explain why I believe this is a bug (although <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=533140#c12"> this comment </a> seems to state the opposite).

By default, when deleting a message from a folder via IMAP, Gmail only removes the label from the message. The message itself is still there, and can still be found in [Gmail]/All mail. This is the preferred behavior for me, because I want to be able to search through messages, while keeping a clean inbox.

However, in Thunderbird 3.0, deleting a message from Inbox will automatically move it to [Gmail]/Trash. Which means the message will be gone in 30 days (or sooner, if I empty the trash folder). This is not something I want to happen.

So I tried setting Thunderbird to move deleted items to "[Gmail]/All mail". However, just as the bug description states, the messages are still moved to [Gmail]/Trash. Which leads me to believe that Thunderbird ignores that setting for Gmail.

As I have stated before, I do not want this to happen, and I do not want Thunderbird second-guessing me about where I want the messages to go.

I know that I can accomplish a similar thing using the "archive" feature, but after years of using "delete", I tend to press it by default. Which can lead to loss of e-mails.

*BUMP*

Just wondering if anyone here might have any info on the status of this bug -- other than what's obviously (not) gone on here? Any chance this is going to be resolved in 3.1? As I and others have said, we'd love to be able to use TB3, but just can't make the switch without this being resolved. Manually moving messages into a custom trash folder (really the only work-around I can think of) just isn't acceptable.

Not that there's any reason to think that it would have been otherwise, but I just wanted to confirm that this is still a problem in 3.1. Also, I've changed the title of this bug report from "Cannot specify custom trash folder using IMAP in Gmail" to "Cannot specify custom trash folder using IMAP". The "in Gmail" has always been misleading, because the problem occurs with any IMAP server, so I went ahead and removed it.

I use a custom mail provider (sud-ouest.org), not gmail.
It cleans up the Trash folder once a week.
I tried to change the Trash folder to MyTrash, to prevent the mails to be killed every week.

I asked, with the UI, that the deleted mails be placed in "Courrier entrant/MaCorbeille", which is french for "INBOX/MyTrash".
It didn't work, and at reboot, I got a new folder "Courrier entrant" with "MaCorbeille" in it.

I checked the value of trash_folder_name in the configurator UI, and it was set to "Courrier entrant/MaCorbeille".
I set it to simply "MaCorbeille" and it worked.

Perhaps the trash folder should be set relatively to the current INBOX, and the UI doesn't handle it correctly.

Perhaps it was the fact that INBOX in french contains a space. This would explain the problem of comment 26 with "[Gmail]/All mail".

Hope this help.

Changing this bug back to "Gmail IMAP only issue".
Problem is due to Tb's particularity for Gmail IMAP.
  [Gmail]/Trash is always used as trash folder, regardless of trash folder
  selection at Server Settings.
Next Gmail's/Gmail IMAP's particularity is relevant to observed phenomenon,
  When a mail is copied to [Gmail]/Trash, any Gmail Label is removed from the
  mail including [Gmail]/All Mail by Gmail/Gmail IMAP
but it's irrelevant to problem of comment #0 itself.
Original problem reported to comment #0 of this bug by bug opener is "trash folder selection at Server Settings is ignored by Tb if Gmail IMAP".

To all proble reporters in this bug for other than Gmail IMAP:

If problem just after trash folder selection change at Server Setting, and if problem while icon for newly selected trash folder is not changed to "Trash Can" icon, read bug 631362, and check whether your problem is same as bug 631362 or not.
If different from bug 631362 and not Gmail IMAP, get IMAP log and check IMAP level flow by yourself, and search bugzilla.mozilla.org well for already reported problem via "Advanced Search" of B.M.O, and, if not found, open separate bug for your problem with attaching log file(never paste), please.

Please note that same external symptom of "trash folder selection at Server Settings doesn't work" is not always same problem.
There are at least several kinds of problem which produces the same external symptom.
(1) This bug, for problem of comment #0, Gmail's particularity relevant problem. Phenomenon of comment #0 is easiliy be reproduced.
(2) bug 631362 (if Gmail IMAP, bug 631362 is irrelevant)
(3) Problem due to localized trash folder name by localized Tb.
    Because localized Tb puts localized trash folder name in prefs.js setting
    of mail.server.serverN.trash_folder_name, it causes mismatch between
    real folder name at IMAP server.
(4) Problem due to namespace.
    Because Tb puts <namespace>/trash-foler-name in prefs.js setting
    of mail.server.serverN.trash_folder_name,
    it causes mismatch between expectation by folder acceess component who
    expects string without namespae in mail.server.serverN.trash_folder_name,
    and <namespace>/<namespace>/trash-foler-name is used as trash folder.
(5) Other than above (1) to (4).

Please keep this bug for problem of above (1) only, for original comment #0 of this bug only.

Richard Livingston(bug opener), please note that this bug opened with your comment #0 is not meta bug for "trash folder selection at Server Settings doesn't work as expected".
Is problem you saw with other than Gmail IMAP is one of (2), (3), and (4) in my comment #30?

As for "Tb ignores trash folder selection at Server Settings if Gmail IMAP"(your comment #0), I don't think it'll be solved soon.
One of best was ways to avoid "automatic purging from [Gmail]/Trash after 30 days by Gmail" is still "Remove immediately" model, or "Just mark it as deleted" model with "auto-expunging of Gmail=Off by Advanced IMAP Controls of Gmail Labs".

With any IMAP delete model, next can be an emulation of ordinal "Move to trash" model, if Gmail IMAP.
(i) Create a Tb's Tag of $$deleted(lowest order) with tag label of "Deleted".
(ii) If you want to delete a mail, add Tb's tag of "Deleted".
      ("1" can be used for shortcut by $$deleted).
      The added tag is shown for copy of mail in any Gmail IMAP folder.
(iii) If you want to purge "mail tagged Deleted", copy(or move) the mail to
      [Gmail]/Trash.
(iv) "Undo of delete" is possible by "remove Tb's tag of Deleted" and
      "copy(or move) back to a folder from [Gmail]/Trash", if within 30 days.
If you create Saved Search folder named "Pseudo-Trash" with "search target folder=[Gmail]/All Mail" and search criterion is "Tag contains Deleted", you can use it as ordinal Trash folder.

FYI.
Reason why Tb currently ignores trash folder selection if Gmail IMAP.
1. Gmail dynamically changes IMAP folder name according to "Display Language:"
   choice by user at Web Interface.
   At Web Interface, folder name of Inbox is also changed to localized name
   according to "Display Language:" if localized name is defined.
2. Real folder name at Gmail IMAP server for special folder is passed in XLIST
   command response which is extention by Gmail.
   According to RFC for IMAP, Inbox is always shown as "Inbox" to IMAP client.
3. Tb currently uses folder returned for trash in XLIST response always.
   Some reasons why:
   3-A. mail.server.serverN.trash_folder_name is static setting.
     To use differet folder as trash folder, the different folder should be
     selected by user via trash folder selection UI at Server Settings.
     (can be called "current restriction", after dynamic folder name change)
     (was introuced by Gmail/Gmail IMAP.)
     If mail.server.serverN.trash_folder_name is always used, Tb can't find
     trash folder when "Display Language:" is changed by user.
     It'll produce unwanted problems, because Trash is very special and
     important folder for current implementation of Tb.
   3-B. If localized Tb, trash folder selection UI stores localized folder name
     for Trash in mail.server.serverN.trash_folder_name. (known bug)
     By "always use trash in XLIST response", this known bug is avoided.
   3-C. After trash selection change at Server Settings, bug 631362 happens.
     By "always use trash in XLIST response", bug 631362 is avoided.
   3-D. If Inbox/Trash is defined, Tb uses Inbox/Trash instead of Trash as
     trash folder(known bug. due to issue in namespace=Inbox support.),
     even when mail.server.serverN.trash_folder_name=Trash or [Gmail]/Trash.
     By "always use trash in XLIST response", this problem is avoided.
So, this bug for Gmail IMAP can be called "current restriction" on Gmail IMAP's trash folder.
This kind of restriction is not applicable to Junk folder selection at Junk Settings and drafts/sent folder selection at Copies&Folders. Junk/Drafts/Sent which is set in Junk Setting/Copies&Folders is always used.

*** Bug 610667 has been marked as a duplicate of this bug. ***

In short, it seems it is not possible to send deleted messages to a folder different than Gmail's default trash folder, which is forcibly deleted by Gmail every 30 days, which means you're screwed if you deleted something by mistake earlier than 30 days ago. Because of that, I think this is a severe limitation of Thunderbird and I think will get rid of it, unless this serious flaw is fixed as soon as possible.

I finally gave up on this, and will be giving up Thunderbird just as soon as I can find a suitable alternative. In the meantime, I've had to just get used to using delete for messages I know I'll never have a need for in the future, and A for archiving/preserving all others (in the All Mail "folder" or any other you designate).

Re Marco & Richard's difficulties above, I believe the answer to Gmail's trash/bin limitation is simply to use T'bird's "archive" feature where you appear to prefer to use T'bird's "delete" feature and reserve the "delete" feature for things you REALLY don't want any more. Should the fact that "delete" REALLY does what it says be considered a bug? With the introduction of T'bird's "archive" feature perhaps this bug should be closed - especially as the bug, if there is a bug, is a bug with Gmail? (See WADA's comments above.)

T'bird's "archive" feature can be set to use Gmail's All Mail - which will persist ad infinitum.

I have a proposed solution to this. I would like some feedback before I attempt a patch.

As WADA mentioned in Comment 32, the reason for the restriction on choosing the Trash folder for a GMail account is that TB is using XLIST to get the trash folder. Whenever TB starts up, the value from the XLIST writes over any user specified value.

There are a couple of ways to work around this:

#1 Patch Thunderbird (aka the hard way)
---------------------------------------
We could add a 4th option to "Account Settings... > <Account> > Server Settings > When I delete a message:"

Current options are:
- Move it to this folder (which is ignored is server supports XLIST)
- Just mark it as deleted (setting recommended by google)
- Remove it immediate

New option would be:
- Use server specified folder

The new option would be selected by default for servers that support XLIST and be disabled for servers that do not support XLIST. Functionally it would work the same as "Move it to this folder" does now.
If the server supports XLIST and "Move it to this folder" is selected, then the value returned by XLIST will be ignored and the user specified folder will be used.

This could be a good thing for other IMAP users (not just GMAil) that want to bypass a server specified Trash folder.

#2 Use an extension (aka the easy way, aka the shameless plug)
--------------------------------------------------------------
There is an extension (that I wrote) for using Thunderbird with GMail - https://addons.mozilla.org/en-US/thunderbird/addon/gmailbuttons/

As I was fixing a problem that was introduced in TB 16 that broke my extension, I came across this bug. It turns out that in fixing the other problem, I have created a work-around for this bug. Note that currently, this only applies to TB 16 and v0.5.0 of the extension (both currently in beta).

If you select the trash folder you want in "Server Settings > Move it to this folder" and click OK, then open the settings again and select "Just mark it as deleted", then the Gmail Buttons extension will "remember" your selection and use that folder for its "Trash" button.

dlech, I've asked irving to comment on your proposal

My preference for the options would be

1) Mark message as deleted
2) Move to the server's Trash folder
3) Move to this folder: <select here>
4) Remove immediately

... with the wording cleaned up by UI review

After fix of Bug 798663(landed on Tb 17.0.2), "Gmail IMAA or not" is detected by X-GM-EXT-1 capability response, and is saved in kGmailImapCapability bit of Capability flags, and is used as indicator of "Gmail IMAP", ad is propaated to s_gmail of prefs.js etc.

As for "forcing [Gmail]/Trash as trash folder", it look done by nsImapIncomingServer::DiscoveryDone() (see bug 829185 comment #11).
Logic of DiscoveryDone() is very simple;
- If Gmail IMAP, force "trash in XLIST reponse" as trash, and clear SpecialUse flag
- If not Gmail IMAP account, respect mail.server.serverN.trash_folder_name.

One of biggest reasons of "forcing [Gmail]/<trash-in-XLIST>" was localized <trash-in-XLIST> by Gmail. Because Gmail/Gmail IMAP changes actual Mbox name to localized name when Display Languge: is changed, and the Display Language: change can be done by user any time, it's very hard to process following variants.
  Trash in en-US Tb, Trash in localized Tb,
  [Gmail]/Trash in en-US Tb, [Gmail]/Trash in localized Tb,
  localized-Trash in en-US Tb, localized-Trash in localized Tb,
  localized-[Gmail]/Trash in en-US Tb, localized-[Gmail]/Trash in localized Tb
Simplest & certain way is "always use trash in X-LIST".

So, "forcing trash in X-LIST" is still mandatory feature.

But, "prohibiting other than trash in X-LIST as trash of Tb" is never proper action of an mailer who supports IMAP.

So, "forcing trash in X-LIST if Gmail IMAP" should be optional, although "forcing trash in X-LIST if Gmail IMAP" should be default.

A possible and simple circumvention of this bug is as follows, altouh it can't be final, absolutely correct, sufficient solution.
  new prefs : mail.server.serverN.force_Gmail_Trash_if_is_gmail(deault=true)
  DiscoveryDone() :
    If Gmail IMAP && mail.server.serverN.force_Gmail_Trash_if_is_gmail_true
       Force trash in X-LIST, clear Trash flag of all other folders,
       as currently Tb does
    Else If Gmail IMAP
       Respect mail.server.serverN.trash_folder_name,
       and clear Trash flag of all other folders
    Else (non Gmail IMAP)
       Do as currently Tb does

However, as I wrote in bug 829185 comment #14, some issues was found in incomingServer.isGMailServer access and incomingServer.trashFolderName access from JavaScript. These may produce new problems if mail.server.serverN.trash_folder_name setting will be used when is_gmail/isGMailServer is true.

Hm, the general solution could be to add a pref in imap "Advanced..." that would disable x-list per server (there's another bug to allow disabling it). And disable folder selection if that pref isn't set and x-list is supported for the server.
You'd anyway get the initial correct folders set up and after you disable x-list you can do whatever you need, for whatever special purposes.

(In reply to Magnus Melin from comment #41)
> Hm, the general solution could be to add a pref in imap "Advanced..." that
> would disable x-list per server (there's another bug to allow disabling it).
> And disable folder selection if that pref isn't set and x-list is supported
> for the server.

You seems claiming that general/final/absolutely correct/sufficient/perferct/... , solution is mandatory...
I'm merely proposing a practical solution what keeps "Forcing of [Gmail]/IMAP as trash for majority of general Gmail IMAP && Tb users" without rejecting request of "using other than [Gmail]/IMAP as trash of Tb" from matured users who understand Gmail/Gmail IMAP well...

If perfect solution is needed for this bug for "trash in Gmail IMAP" only, I believe this bug is better closed as dup of bug 800035 what requests perferct solution in bug 800035 comment #2 for any of Trash, Junk, Archive, and Drafts/Sent.

Well, if not mandatory, a "real" solution is at least preferred.

After fix of Bug 798663(status-thunderbird-esr17:fixed, landed on Tb 12.0.2) which resolved problem of Bug 815087, Tb 17.0.2 detects "Gmail IMAP or not" correctly, so problem of this bug(Trash) and a part of bug 800035(Archive) was exposed to users who are using Gmail IMAP for long time with mail.server.serverN.hostname!=imap.gmail.com.
(a) Trash case : bug 829185
    hostname=imap.googlemail.com case.
    By auto-config, hostname=imap.googlemail.com is used, perhaps by definition
    order in ISPDB.
(b) Archive case : bug 705491 comment #13
    Although "other than [Gmail]/All Mail" can be selected at UI and is used,
    "Archives Options..." is disabled and "archive to .../yy/mm" is impossible.

"Real" solution for them is "they can continue to use Tb without big change in their daily operation".

Because "Gmail IMAP detection" is sorted out by bug 798663(now based on X-GM-EXT-1 obtained by CAPABILITY response upon each login), there is no need to keep is_gmail flag in prefs.js any more.

If meaning/usage of is_gmail in prefs.js will be changed,
  (a) If no X-GM-EXT-1, clear is_gmail in prefs.js.
      (mandatory to bypass problem like Bug 815087)
  (b) If X-GM-EXT-1 is detected, never write/update is_gmail of prefs.js.
  (c) If is_gmail=false of prefs.js is set by user,
      override(clear) higher level "Gmail IMAP indicator" which is inherited
      from kGmailImapCapability bit of eIMAPCapabilityFlag.
they can use "trash other than [Gmail]/Trash" without any other change in Tb including correct solution of bug 800035.
And, they can archive mail to "yy/mm under [Gmail]/All Mail" and "yy/mm under Archives" even with Gmail IMAP.

This is another way to make "Forcing [Gmail]/Trash as trash of Tb if Gmail IMAP" optional.

As for Trash, there is no need to copy deleted mail to Trash in IMAP(\Deleted flag is used), and there is no reason to hate "Just mark it as deleted". So, I don't think such change is mandatory and has highest priority.
However, for users who used Tb & Gmail IMAP with "other than [Gmail]/Trash as Tb's trash" for long time, with undestanding Gmail IMAP well, this bug is a regression and such change is mandatory for their convenience.

(A) Reason why I proposed new mail.server.serverN.force_Gmail_Trash_if_is_gmail in comment #40.

Usage of is_gmail I showed in comment #44 is similar to useCondStore - user can override "CONDSTORE returned in CAPABILITY response" by useCondStore=false in prefs.js.
However, isGMailServer/is_gmail is also used for getting X-GM-MSGID, X-GM-THRID, X-GM-LABELS from Gmail IMAP. So, "override by is_gmail=false" can't be used for disabling "Forcing [Gmail]/Trash".

(B) Reason why I proposed simple "new mail.server.serverN.force_Gmail_Trash_if_is_gmail" and "small logic change in nsImapIncomingServer::DiscoveryDone()" in comment #40.

Current trash selection UI at Server Settings has some big problems:
  - Isn't torelant with localized folder name in localized Tb.
  - Isn't torelant with namespace.
  - Isn't torelant with "IMAP Server Directory:" and it's change by user.
And, similar folder selection UI to Copies&Folders and Junk Settings, which automatically resolves above problems, is already proposed.
So, correct UI enhancement such as "use folder in XLIST" should be consistent with other UI changes and should be consolidated to other UI changes.
And, there is already known problem in Copies&Folders and Junk Settings when XLIST or LIST(EXTENDED) is used : bug 800035.
Further, workload of big UI change is not so small, and it usually takes long.

*** Bug 832308 has been marked as a duplicate of this bug. ***

I'm amazed this bug is almost 4 years old. This feature was working fine for me up until I "upgraded" to v17.0.2 from 16.0.2. Downgrading back to 16 didn't fix this. This is annoying to say the least because Gmails Trash retention is only 30 days and I prefer to keep my Trash longer.

A workaround I found is:
1) disable "Show In IMAP" under Settings>Labels in the Gmail web interface for the Gmail Trash folder
2) unsubscribe from the Gmail Trash folder in TB

Both actions seem to allow permanent setting of an alternate trash folder. This is not ideal however since access to the Trash folder is then lost via IMAP.

To elaborate: the workarounds mentioned above are either/or.

Created attachment 704299
Test extention : Change arbitary IMAP folder to trashFolderName folder and SpecialUse=Trash folder by ToolBar button click

This test extension is for seeing Tb's behavior on "trash", and merely does following when customized ToolBar button-1 is clicked.

(1) Puts currently selected folder name to incomingServer.trashFolderName
    if IMAP account. (call ABC/DEF for later reference)
(1-A) Use string in msgFolder.URI instead of msgFolder.prettiestName
    for setting incomingServer.trashFolderName, in case of localized special
    folder name by localized Tb.
(1-B) Remove personalNamespace from string set in msgFolder.prettiestName,
    because Tb's current logic which uses mail.server.serverN.trash_folder_name
    requests "Mbox name without namespace" in trash_folder_name setting.
Note: This test extension doesn't care about "IMAP server directory:" of Server Settings/Advanced.

By (1), Tb automatically updates mail.server.serverN.trash_folder_name and is automatically reflected to trash folder selection UI at Server Settings.
This works very well, as far as problem of bug 831664 is bypassed by operation like "write very long text to Error Console".

(2) Request msgFolder.setflag(Trash) for selected folder of ABC/DEF
    and msgFolder.clearflag(Trash) for all other folders under the IMAP account.
    (this is opposite action to DiscoveryDone().)

By (2), icon of selected folder of ABC/DEF is changed to trash-can-icon, and trash-can-icon is removed from any other folder including [Gmail]/[Trash] of Gmail IMAP.

Even when Gmail IMAP, folder of ABC/DEF is used by Tb as "trash for Tb" when IMAP delete model of "Move to trash" and mails are moved to ABC/DEF when delete is requested, until collapse/re-expand, subscribe, unsubscribe etc. is executed,

When Gmail IMAP account is collapsed/re-expanded, following is observed.
  Upon re-expand, trash-can-icon is removed from ABC/DEF,
  and icon of [Gmail]/Trash is changed to trash-can-icon.
This is done by following.
> http://mxr.mozilla.org/comm-central/source/mail/base/content/folderPane.js#881
> 881 if (aExpandServer) {
> 882 if (folder.isServer)
> 883 folder.server.performExpand(msgWindow);
> http://mxr.mozilla.org/comm-central/source/mailnews/imap/src/nsImapIncomingServer.cpp#941
> 941 nsImapIncomingServer::PerformExpand(nsIMsgWindow *aMsgWindow)
> 962 rv = imapService->DiscoverAllFolders(rootMsgFolder,
> http://mxr.mozilla.org/comm-central/source/mailnews/imap/src/nsImapService.cpp#1811
> 1811 NS_IMETHODIMP nsImapService::DiscoverAllFolders(nsIMsgFolder *aImapMailFolder,
> 1834 urlSpec.Append("/discoverallboxes");
> 1838 rv = GetImapConnectionAndLoadUrl(imapUrl, nullptr, aURL);
After completion of the discoverallboxes request,
> http://mxr.mozilla.org/comm-central/source/mailnews/imap/src/nsImapIncomingServer.cpp#2331
> 2331 nsImapIncomingServer::OnStopRunningUrl(nsIURI *url, nsresult exitCode)
> 2350 case nsIImapUrl::nsImapDiscoverAllBoxesUrl:
> 2351 if (NS_SUCCEEDED(exitCode))
> 2352 DiscoveryDone();

Test result of (1) indicates possible new/easy trash selection for user,
  Context menu of "Use thi...

Even if correct solution like "use folder in XLIST" in UI will be implemented, logic in DiscoveryDone() on trash folder should be changed to one like next;
> If (GmailIMAP && A_Flag==1) { force [Gmail]/Trash in XLIST ; }
> Else if (GmailIMAP && A_Flag==2) { don't force [Gmail]/Trash in XLIST ; }
> Else if (!GmailIMAP) { same as current }
I merely called the A_Flag "force_Gmail_Trash_if_is_gmail", and I merely proposed it as "a new boolean of prefs.js".

(In reply to ncnmra from comment #47)
> A workaround I found is:
> 1) disable "Show In IMAP" under Settings>Labels in the Gmail web interface
> for the Gmail Trash folder
> 2) unsubscribe from the Gmail Trash folder in TB

Logic on trash in DiscoveryDone() was one like following;
      <= At this stage, trash in XLIST is perhaps already set as SpecialUse=Trash
         (perhaps only when IMAP delete model = "Move to trash" model)
  Search SpecialUse=Trash folders.
  If(number of SpecialUse=Trash folder>1) // Keep single SpecialUse=Trash folder
    For each SpecialUse=Trash folder
     If(Gmail){ if trash in XLIST, setflag(Trash); else clearflag(Trash); }
     Else{if folder of trash_folder_name, setflag(Trash); else clearflag(Trash);}
By your workaround, number of SpecialUse=Trash folder is changed to 1.
I think it's reason why your workaround works.

*** Bug 829185 has been marked as a duplicate of this bug. ***

As far as the workarounds on comment #47: I ended up preferring #2 because #1 will remove [Gmail]\Trash from other IMAP clients that don't exhibit TBs behavior. In my case, this created a problem with my iPhone and it attempted to created its own Trash folder.

Workaround #1 seems to work for now with the exception that I cannot access the [Gmail]\Trash folder from TB. I'm not sure how this influences Shift-Delete behavior since I don't usually use it.

(In reply to ncnmra from comment #53)
> I'm not sure how this influences Shift-Delete behavior since I don't usually use it.

"Shift+Delete" is "Delete without copy to trash when move to trash model" in Tb. This is similar to MS Window's Shift+Delete of file/directory.
When IMAP, "delete a mail"=="store +Flag (\Deleted)".
Difference from perspective of IMAP is;
  "Move to trash" model :
     Delete : "uid xxx copy trash" + "uid xxx store +Flag \Deleted"
     Shift+Delete : "uid xxx store +Flag \Deleted"
  "Just mark it as deleted" / "Remove immediately" :
     Delete / Shift+Delete : "uid xxx store +Flag \Deleted"
i.e. "Shift+Delete" is never influenced by "unsubscribe [Gmail]/Trash".

> Workaround #1 seems to work for now with the exception that I cannot access the [Gmail]\Trash folder from TB.

If you want to copy/move mail to [Gmail]/Trash, subscribe it again.
  subscribe [Gmail]/Trash, collapse/expand account if required,
  copy/move mails to [Gmail]/Trash or delete mails while trash==[Gmail]/Trash,
  unsubscribe [Gmail]/Trash again.
As far as auto-expunge of Gmail is enabled, any Gmail Label is removed from mail and mail flagged as \Deleted is automatically removed(expunged) from IMAP folder(s) by Gmail, and mail is removed from [Gmail]/All Mail too by Gmail, and the mail will be permanently erased at [Gmail]/Trash after 30 days.

Another solution of issue of "you can't acces [Gmail]/Trash if unsubscribed".
  Use "Just mark it as deleted" or "Remove immediately".
I think "adding Gmail Label of [Imap]/Trash or Something/Trash by move to trash model and deleting mail in Tb" is convenient, but I don't think it's mandatory for any Gmail IMAP & Thunderbird user.

A problem in workaround of "unsubscribe [Gmail]/Trash".
  Even when you unsubscribed [Gmail]/Trash at Thunderbird
  with "Show subscribed folders only" option,
  if other IMAP client who shares same Gmail IMAP account subscribes [Gmail]/Trash,
  [Gmail]/Trash is used as tash in Tb again sooner or later.

These are not valid workarounds for me. A valid workaround would be to train myself to MOVE an email to the Trash folder rather than use Delete (or find some extension that maps the Delete key and functionality to "Move to Trash").

I find it unacceptable that a certain functionality in TB that worked a certain way since the early days of TB is removed overnight in a minor .2 update and bug 829185 is marked as a duplicate of this bug that has been open for over 3 years with not signs of being fixed any time soon. I think the Trash functionality present before 17.0.2 must be restored in the next 17.0.x update, I consider it a regression. Thank you.

(In reply to Tim K from comment #56)
> (or find
> some extension that maps the Delete key and functionality to "Move to
> Trash").
>

You may find this useful.

https://addons.mozilla.org/en-us/thunderbird/addon/gmailbuttons/

Doesn't have binding to delete key, but at least it has a 'move to trash' button.

(In reply to WADA from comment #55)
> A problem in workaround of "unsubscribe [Gmail]/Trash".
> Even when you unsubscribed [Gmail]/Trash at Thunderbird
> with "Show subscribed folders only" option,
> if other IMAP client who shares same Gmail IMAP account subscribes
> [Gmail]/Trash,
> [Gmail]/Trash is used as tash in Tb again sooner or later.

I haven't noticed this phenomenon yet. my Gmail IMAP account is shared via my iPhone, and my TouchPad (running Android). After Unsubscribing from the [Gmail]\Trash folder, TB is still using my custom "Deleted" folder when I delete a message.

@Tim: I agree- this is annoying, but I'm hopeful my workaround is temporary, mind you I get the feeling that the current mode of operation of TB is considered "correct" :( You can always use the web interface to access Gmail's Trash. I never use Shift-Delete, and my iPhone is set to delete mail to trash, so I use it when I want to clear out messages I know I won't need.

FYI.
A way to access [Gmail]/Trash from Thunderbird again to copy/move mails to [Gmail]/Trash, after unsubscribing [Gmail]/Trash in order to use "other than [Gmail/Trash" as trash of "move to trash" model.
(A) Change to "Just mark it as deleted", subscribe [Gmail]/Trash, copy/move mails to [Gmail]/Trash, unsubscribe [Gmail]/Trash, go back to "Move to trash" model.
(B) Create two same Gmail IMAP accounts in a Tb with different server name,
 (i) with hostname/realhostname = imap.googlemail.com (auto-config only)
 (ii) with hostname/realhostname = imap.gmail.com (auto-config with Manual Setup)
and set different options.
 (i) As you want for your daily use, with "Show subcribed folders only"
 (ii) All folder is Offline-use=Off, Just mark it as deleted,
      disable "Show subscrbed folders only", disable IDLE comand use,
      max cached connections=1, disable automatic new mail check, ...

All this time spent on identifying workarounds and the bug has been open for 3+ yrs... any hope to actually see a proper fix for it, please? Thanks.

FYI.
Needless to say, IMAP delete model of "Just mark it as deleted"(with View/Undeleted if required), is always an effective workaround, because Tb doesn't move mails to trash upon "mail delete" according to design of protocol named IMAP when "Just mark it as deleted" and "Remov immediately".

I found this bug recently after discovering that I have been losing emails I had not intended to lose for an indeterminate period of time. I am deeply angry, and I believe rightly so.

I have a gmail account. I'm using Thunderbird 31.6.0 on Ubuntu linux. The thunderbird UI clearly states, under Account Settings / Server Settings:

"When I delete a message:"

and gives three options, one of which is:

"Move it to this folder: " with a selection box.

I selected [Gmail] -> All Mail. Instead, when I push delete, the message is not moved to that folder, but is moved to the [Gmail] -> Trash folder.

Why, in the name of all that is decent and human, is that UI option not simply removed, or greyed out, or annoted with a "this doesn't always work" message, or SOMETHING, INSTEAD OF BEING SILENTLY IGNORED? The thunderbird UI is lying to me, and I lost data because of it.

I really like thunderbird. I love that it gives me a really nice way to use OpenPGP. I love that it is open source. I love that it is clean an functional.

I understand (now) that I can just push 'a' instead of <Delete>, and use the archive function. If it was just a matter of having to use a different keyboard shortcut, that would be fine.

I understand (now) that it is a little complicated to fix this due to Google changing the text label of the All Mail folder under certain conditions. I only mostly followed the technical details given by WADA and others over the course of this thread. Maybe I've gotten some detail of that statement wrong. It doesn't really matter. Ignoring the option is not the problem. Special cases for gmail are not the problem. The problem is that the UI said it would do one thing and in fact did another, causing me to lose data.

This bug, it seems to me, highlights a deeper problem. The problem is not that the code hasn't been refactored to either gray out that option or make it do what it says. I understand that this is difficult and time consuming for developers, and that there are other priorities, and that this is a somewhat obscure option. The problem is that nobody seems to have thought about this problem from the perspective of the user. Even a static text message above that option would be preferable to what we have now. It could say something like:

"Note: this setting is ignored in some cases. See <link>."

Heck, even without a link to more explanation it would be preferable to what we have now.

To all problem repoters:
Which is actual problem of this bug? Or which is actual request?
(A) Because "trash selection UI" accepts other tha [Gmail]/Trash as "trash folder in Tb for Gmail IMAP aaccount",
      Tb must respect the user's trash folder choice by user, even if this is Gmail account.
      Tb users know Gmail's particularity pretty well.
      i.e. UX bug.
(B) "Always Use [Gmail]/Trash (localized name by Gmail if Display Language in Gmail is not English)" is reasonable and aacceptable.
      "trash selection UI" must not accept trash folder selection change if Gmail IMAP.
      "trash selection UI" must not lie on actual trash folder selection.
      i.e. UI bug.

Root cause of confusions by users in this bug is "mismatch between UX and UI".
Second cause is that Tb users usually never try to read "User's Guide or Manual of Gmail/Gmail IMAP provided by Gmail", even though "particularity of Gmail/Gmail IMAP" surely exists. Who is responsible to the "particularity of Gmail/Gmail IMAP" is never Thunderbird Developers. Who is responsible is surely Gmail/Google. Gmail's recommendation is "Remove it immediately" because Auto-Expunge of Gmail IMAP is enabled by default.

FYI.
For "Archive granularity", [Gmail]/All Mail is used as Archive folder by default.
So, solution like (B) is already introduced to avoid user's confusions.
      "Archive granularity" option is disabled in UI if Gmail IMAP.

I recently discovered this problem and wanted to share a workaround that preserves key parts of my preferred use model:

(1) I can press the Delete key on the keyboard, or the delete button in the GUI, to remove mail from my Inbox (or other folders), while preserving them in a folder (All Mail) where messages are not automatically deleted after 30 days.

(2) I can periodically purge old messages at a timeframe of my choosing, in a simple way.

I'm achieving (1) as follows:

In Thunderbird:

Account Settings->Server Settings->When I delete a message: "Remove it immediately"

"Remove it immediately", in the context of Gmail, doesn't have the same outcome as it might on other conventional IMAP servers. It does set the IMAP "Deleted" flag on the message, but in Gmail, all that effectively does is only remove it from the current folder. The message remains accessible in Gmail's "All Mail" folder.

In Gmail:

Settings->When I mark a message in IMAP as deleted: "Auto-Expunge on"

This just simplifies things for my use case by ensuring that Gmail's actions are immediately synced up with Thunderbird's actions.

References:

https://support.google.com/mail/answer/77657
https://support.google.com/mail/answer/78755
https://support.google.com/mail/answer/78892

I'm achieving (2) with the following Google Apps Script:

https://script.google.com/d/1xWTKAwhyul0SVGYrhWdHSMX1wylsfemcjmrsUX6NwxE1Jzj9_M53uJEG/edit?usp=sharing

This script automatically moves messages in "All Mail" older than 3 years into Gmail's Trash folder, where they will be then subject to Gmail's autodeletion policy. It excludes unread messages, Inbox messages, and messages that are in any of my user folders.

With Resources->Current project's triggers, I have set this to automatically run every month.

FYI.
"Archive button for delete mail", "Mark as Junk button for delete mail" is not good workaround, because bad side effect occurs and it's pretty confusing.
Another simple solution for power users/who understand Gmail/Gmail IMAP well.
- Any user can add toolbar button by "Custom Buttons" addon.
  And, such job is pretty easy for users who requested solution for this bug.
- Button script for "copy/move selected messaages to a mail folder" is pretty simple.
    Simply request "copy/move selected messaages at Thread pane to a mail folder".
- Create a button for "ordinal delete" == move to a Gmail Label which you want
  Create a button for "permanent delete" == copy to [Gmail]/<Localized trash at Gmail>"
  Because of your private script, hard-coded folder name is sufficient.
- GetSelectedMsgs() : returns currently selected messages at Thread pane.
  SharedScript(msgDBHdrs,TargetFolder,MoveMode) :
      copy mails to requested folder, if MoveMode~=true, delete msgDBHdrs.
  For "ordinal delete" : SharedScript(GetSelectedMsgs(),<Gmail Label you want>,true)
  For "permanet delete" : SharedScript(GetSelectedMsgs(),[Gmail]/<Localized trash at Gmail>)
- If required, create EmptyGmailTrash button when IMAP trash model != move to trash.
  because "Empty Trash" is greyed out if IMAP trash model != move to trash,
  "Select All + Shift+Delete at [Gmail]/Trash" is sufficient though.

(In addition to comment #65)

If "top level Trash at folder pane of Tb" could be used as "trash in Tb"("delete mail" moves mail to it) in Tb 31 with addon even with imap delete model=Remove it immediately or just mark it as deleted, reason is next.
  In Tb, "trash folder used by Delete Mail/Empty Trash" = first found folder which has Trash atribute in Tb.
  "Trash atribute in Tb" is shown as "trash can icon" at folder pane.
  Because top level Trash is found before [Gmail]/Trash fy folder tree scan, even if both has "trash can icon",
  top level Trash is used as "trash used by delete mail" as far as "trsh can icon" is kept in the folder.
When Tb uses [Gmail]/Trash as "trash in Tb", Tb clears "Trash attribute" of all other folders under the IMAP accout, in order to keep "only one folder is trash in an IMAP account", or when change to "Remove it immeditely" or "Just mark it as deleted", Tb perhaps clears "Trash attribute2 of all folders under the IMAP account.
This is reason why "trash can icon" of "top level Trash at folder pane of Tb" is cleared.

Sorry coment #66 is poting to wrong bug. Ignore it, please.

Following in comment #65 is not easily applicable to "Delete key" user.
  Button script for "copy/move selected messaages to FolderUserWants"
Key assignment change for "Delete Key" is needed, but it's not so easy even thoogh the key assignment change is simple job(it's merely a key assignment change, but side efects etc. should be fully cared because Delete key.)

So, your own Toolbar button like next may be better for "Delete key" users.
  When clicked, store Trash attribute to your own trash,
  and if Gmail IMAP, register eventListener for the folder.
  When eventListener detects "removal of Trash attribute from my own trash by Thunderbird",
  Anti Tb+Gmail feature wakes up:
    store Trash attribute to my own trash,
    and immediately clear Trash attribute of [Gmail]/Trash if [Gmail]/Trash exists.
    this is start of endless war with "Dark Tb+Gmail" :-)
  Merit of above : Applicable to all [Gmail]/Trash is shown case, hidden case, unsubscribed case,
  Problem of above : If Tb is restarted, "your own trash" looses Trash attribute until you click button again.

FolderFlags addon may behave like above, because following was reported in bug 1175446.
  When [Gmail]/Trash is hedden by Gmail,
  if "his own trash" is set as "folder which has Trash attribure, which has trash can icon" by the addon,
  "trash can icon" of the "his own trash" is kept until restart of Thunderbird.
Can some one check with FolderFlags addon?

I've just realized that I have also been losing messages because the UI does not do what it says it does.

I want the Delete key to move messages to a custom trash folder where they will not be automatically destroyed by Google.

The UI should not lie to me.

For those following this with hopes of a resolution, I wanted to add one thing, and give a work around.

The behavior will work as expected if when you load Thunderbird, you immediately go into the Account Settings and change this setting to "Remove it Immediately", and click "Ok". Then go back in and set it to "Move it to this folder:" and click "Ok". This seems to hold the preference and work correctly until Thunderbird is restarted. Once it's restarted, you have to do this again. Hopefully this can help the developers come up with a fix.

WORKAROUND:

If you're like me, and you preferred this functionality in Thunderbird, you can do what I did. I downloaded the Mozilla KeyConfig add-on, changed the settings for my backspace and delete keys to "Archive" the message. I then changed my Archive folder in "Account Settings -> Copies & Folders" to point to my previously used custom "Trash" folder (I had labeled mine "Trash_" to keep it separate from Gmail Trash.

This won't work if you right click an email and delete, however if you're always using the keyboard for deleting messages like me, this will hopefully give you an adequate resolution.

I am ready to accept the reasoning behind treating Gmail as a special case, and disallowing the use of user-specified folder as the trash folder.

But I think that lying to the user is unacceptable. If user's selection of the trash folder is going to be ignored, the user must be told so. Either by not allowing him/her to select that option, or at least by showing them an error message like "this option does not work for Gmail". Currently (52.1.1, eight years since the bug was reported) Thunderbird lets the user select the trash folder, but silently continues to use a different folder.

*** Bug 1381217 has been marked as a duplicate of this bug. ***

Can we simply disable the user interface elements if the Account is Gmail? It is bad design to leave available a user interface element we know will not work.

Just found out about this issue. I confirm that the option "When I delete a message, move it to this folder:" works except for GMail account.

Disabling the option in Server Settings like Matt said and/or a note saying that this feature doesn't work with GMail would be very appropriate. Easy and quick fix.