Tim K Reporter
	Description • 12 years ago

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0
Build ID: 20130104151925

Steps to reproduce:

Thunderbird 17.0.2 on Windows 7 x64

Just updated to TB 17.0.2 on Win7 x64 and it seems the designated Trash folder in the Gmail IMAP account settings is no longer honored. I have my Gmail IMAP account configured in TB to use the [Imap]/Trash folder rather than Gmail's default Trash folder. This used to work fine up until TB 17.0.2, on delete messages would get moved to [Imap]/Trash and the folder would get the trash icon. Starting with 17.0.2 the [Imap]/Trash folder no longer has the trash icon and even though the option in Server Settings is set to Move it to this folder: Trash (the folder [Imap]/Trash is selected, not Gmail/Trash), deleted messages are moved to Gmail/Trash instead.


Actual results:

Deleted message went to Gmail/Trash instead of the designated [Imap]/Trash per Server Settings.

The designated Trash folder ([Imap]/Trash in this case) no longer has the trash icon.


Expected results:

Deleted messages should go into the designated folder per the Server Settings, in this case [Imap]/Trash.

The designated Trash folder ([Imap]/Trash in this case) should have the trash icon.

	WADA:World Anti-bad-Duping Agency
	Comment 1 • 12 years ago

What *FOLDER* name at where are you talking about?
>  -----------------------------  ------------------------------------------------------------------------------------
>  Gmail's Web Iterface           Mbox name for IMAP client
>  (some are called Folder)       (Mail folder at mail client)
>  (some are called Gmail Label) 
>  -----------------------------  ------------------------------------------------------------------------------------
>  Inbox                          Inbox             <= always Inbox in IMAP(case insensitive)
>                                                      "system label" of Gmail,
>                                                      but is similar to ordinal Gmail Label
>  -----------------------------  ------------------------------------------------------------------------------------
>  Drafts                         [Gmail]/Drafts    <=  "system label" of Gmail, similar to ordinal Gmail Label
>  Sent Mail                      [Gmail]/Sent Mail <=  "system label" of Gmail, similar to ordinal Gmail Label
>  Starrred                       [Gmail]/Starrred  <=  "system label" of Gmail, similar to ordinal Gmail Label
>  -----------------------------  ------------------------------------------------------------------------------------
>  All Mail                       [Gmail]/All Mail  <=  Special *folder* of Gmail
>  Spam                           [Gmail]/Spam      <=  Special *folder* of Gmail
>  Trash                          [Gmail]/Trash     <=  Special *folder* of Gmail
>  -----------------------------  ------------------------------------------------------------------------------------
>  [Imap]/Drafts                  Drafts            <= similar to ordinal Gmail Label, default at Tb's Copies&Folders
>  [Imap]/Sent                    Sent              <= similar to ordinal Gmail Label, default at Tb's Copies&Folders
>  Archives                       Archives          <= ordinal Gmail Label,            default at Tb's Copies&Folders
>  Templates                      Templates         <= ordinal Gmail Label,            default at Tb's Copies&Folders
>  Junk                           Junk              <= ordinal Gmail Label,            default at Tb's Junk Settings
>  [Imap]/Trash                   Trash             <= similar to ordinal Gmail Label, default at Tb's Server Settings
>  -----------------------------  ------------------------------------------------------------------------------------

Are you talking about phenomenon of bug 533140? (see also bug 800035)

That bug cen be easily found by very simple "Advanced Search" like "bug sumary contains Gmail && Trash, status=---(open)". Because hit bugs are only 10 bugs, there is no need to add other condition to reduce listed number of bugs.
Why you couldn't find already opened bug before your bug open?

> Just updated to TB 17.0.2
> Trash folder in the Gmail IMAP account settings is no longer honored.

As known by bug 533140, it's phenomenon since Tb 3 and it's never by recent change.
From which version of Tb did you upgrade?

By the way, please read bugs listed in Dependency tree for meta bug 402793 well before open bug for Gmail IMAP.

	Tim K Reporter
	Comment 2 • 12 years ago

No, this stopped working for me with the 17.0.2 update. I updated from 17 or 17.0.1 whatever the previous most recent version was, I always stay up to date. That's certainly new behavior for me, not since TB3.

I configured my IMAP manually long time ago and it's a Google Apps account, the email does not end in @gmail.com so perhaps that's why TB didn't recognize it as a Gmail account until the 17.0.2 update?

Any workarounds?

	Tim K Reporter
	Comment 3 • 12 years ago

Just to clarify the folder names, using the IMAP names listed above:

Server Settings: I have selected Trash. I checked prefs.js too and it's "Trash".

When I delete a message it goes to [Gmail]/Trash instead of Trash.

Once again for me this behavior started with 17.0.2, it worked as I wanted it to up until now.

Here's what I have for Server Name: imap.googlemail.com
User Name: something@hosteddomain.com           (this is not @gmail.com)
Email Address: something-else@hosteddomain.com  (this is not @gmail.com)

	Wayne Mery (:wsmwk)
	Comment 4 • 12 years ago

Tim, can you please revisit https://ftp.mozilla.org/pub/mozilla.org/thunderbird/releases/17.0/ to confirm that it indeed still works there?

	Tim K Reporter
	Comment 5 • 12 years ago

I tried 17.0 from the link above. Here are my findings:

(1) I installed 17.0 on top of 17.0.2, in other words I didn't uninstall anything first and used the exact same profile as for 17.0.2 - it didn't go well, the problem where the Trash folder settings was not honored was still there.

(2) With the same installation, I moved the "17.0.2" profile out of the way and put in its place a "17.0" backup of my profile from the day before I upgraded to 17.0.2
Success this time! The behavior I'm used to where the Trash setting from Server Settings is honored worked as expected. I will stay with 17.0 and this profile until the issue is addressed.

My conclusion is that this is a regression in 17.0.2 and that 17.0.2 does something to the profile where going back to 17.0 is not sufficient, something else in the profile needs to also be reverted.

I went a step further and diff'ed prefs.js from the 2 profiles:
17.0.2 profile has this:
user_pref("mail.server.server1.is_gmail", true);
while the 17.0 profile does not have it at all.

Now, I went back to 17.0.2 with the 17.0.2 profile and changed prefs.js to:
user_pref("mail.server.server1.is_gmail", false);
Unfortunately it doesn't work, TB 17.0.2 flips it back to true. If I change it to false via about:config it works for that session, but if I restart TB 17.0.2 then it's back to true. Removing the line doesn't help either, TB 17.0.2 insists in setting it back to true.

It seems that detecting Gmail accounts has been "improved" in 17.0.2 resulting in a behavior regression that affects some users.

The reason why I want a different Trash folder:
* on Delete I want the deleted message to go to Trash. I manage my Trash folder based on my own expiration rules, I don't like the automatic 30-day purge in Gmail.
* on Shift-Delete I like that the messages go to [Gmail]/Trash. I do that for messages that I don't really care for to keep for more than 30 days and it's a good safety net if I hit Shift-Delete by accident on something I need, there's a place to recover the messages from.

I hope this regression will be addressed soon or I'm stuck on build 17.0

Thank you!

	WADA:World Anti-bad-Duping Agency
	Comment 6 • 12 years ago

(In reply to Tim K from comment #5)
> I went a step further and diff'ed prefs.js from the 2 profiles:
> 17.0.2 profile has this:
> user_pref("mail.server.server1.is_gmail", true);
> while the 17.0 profile does not have it at all.
(In reply to Tim K from comment #2)
> No, this stopped working for me with the 17.0.2 update. I updated from 17 or
> 17.0.1 whatever the previous most recent version was, I always stay up to
> date. That's certainly new behavior for me, not since TB3.

Actually affected by change between Tb 17.0.1 and Tb 17.0.2 in your case.
Perhaps Bug 798663(status-thunderbird-esr17:fixed) which resolved problem of Bug 815087.

> I configured my IMAP manually long time ago and it's a Google Apps account,
> the email does not end in @gmail.com so perhaps that's why TB didn't
> recognize it as a Gmail account until the 17.0.2 update?

What is your server definition in prefs.js?
  mail.server.serverN.hostname
  mail.server.serverN.realhostname
  mail.server.serverN.userName
  mail.server.serverN.realuserName
Your case is perhaps following.
  Due to hostname != imap.gmail.com, is_gmail=true was not set before Tb 17.0.2.
  After fix of Bug 798663, is_gmail=true is correctly set when actual Gmail IMAP.

(In reply to Tim K from comment #5)
> I don't like the automatic 30-day purge in Gmail.

If so, why you don't use IMAP delete model of "Just mark it as deleted"?
- If this IMAP delete model, Tb simply stores \Deleted flag to mail by "Delete".
- Gmail IMAP merely removes Gmail Label which corresponds to IMAP folder name.
- When Gmail's auto-expunging=On, the mail automatically disappears from folder.
- Unless you intentionally copy or move a mail to [Gmail]/Trash or [Gmail]/Spam,
  the mail is held in [Gmail]/All Mail forever.
  (Gmail IMAP returns OK to "store -Flag(\Deleted)" at [Gmail]/All Mail.)
  (But Gmail IMAP doesn't hold \Deleted flag if [Gmail]/All Mail.       )
  (So, the mail's "deleted status" automatically disappears if [Gmail]/All Mail.)

If you need "ordinal Trash folder" like one for Gmail IMAP, Tb's Star and [Gmail]/Starred can be used in conjunction with "Just mark it as deleted". 
  your new Delete operation in Tb == Mark as "Starrred"
                                     ( + "Delete or Shift+Delete" if needed ) 
  your new Trash folder in Tb     == [Gmail]/Starred
  (Simply use \Flagged as your "mark of deleted mail" instead of \Deleted.)
  (Use \Deleted flag for removing Gmail Label.)

	Tim K Reporter
	Comment 7 • 12 years ago

I have:
user_pref("mail.server.server1.hostname", "imap.googlemail.com");

So yes, hostname != imap.gmail.com

I don't understand why TB forces a certain behavior, that's not how I work. I was perfectly happy with the way things worked for me before 17.0.2

If TB wants very tight integration with Gmail, then it should remove all the Server Settings and not let the user specify any of the special folders at all, such as Trash, Drafts, etc. But I don't like this model. I access the same Gmail account from multiple IMAP clients 99% of the time (phones, tablets, desktops running different OSes, etc.) and they all seem to agree on using Trash, Drafts, Sent, etc. and not use [Gmail]/* unless I tell them to do so which I don't bother to do.

Thanks for your suggestion, but I'm not going to change the way I work just because of a Thunderbird change.

I think TB should allow me to at least set is_gmail=false for the account and not flip it back to true for me. if it's a user preference it should honor it as is, just like it should honor the rest of the preferences.

	WADA:World Anti-bad-Duping Agency
	Comment 8 • 12 years ago

(In reply to Tim K from comment #7)
> I think TB should allow me to at least set is_gmail=false for the account
> and not flip it back to true for me. if it's a user preference it should
> honor it as is, just like it should honor the rest of the preferences.

What is reason why you repeat stating at here about already known phenomena/issues/problems by other existent bugs which I already pointed?

If this bug is for "*BY UPGRADE TO TB 17.0.2* from 17.0.1, phenomenon of bug 533140 started to occur", INVALID or WONTFIX, because change by Bug 798663 is correct thing. 
If this bug is for "problem/phenomenon of bug 533140" or "request of bug 800035", DUP.

A reason why "[Gmail]/Trash is best one as trash of Tb" is that "keeping same Delete behavior as Delete at Gmail's Web Interface when IMAP delete model of Move to trash" is a best thing for majority of general Tb users. 
"Forcing [Gmail]/Trash" is perhaps because of "trash folder selection related problems what occurred in the past with Gmail IMAP".

However, there is no reason to prohibit "using other than [Gmail]/Trash as trash folder of Tb when IMAP delete model of Move to trash".
> Tb requests (a) "uid xxx copy TrashX", and (b) "uid xxx store +Flag(\Deleted)".
> By (a), (c) Gmail adds Gmail Label of TrashX to original mail in [Gmail]/All Mail(call UID=zzz).
> By (b), (d) Gmail removes Gmail Label of Inbox from the mail(UID=xxx in Inbox, UID=zzz in [Gmail]/All).
> By (d) and auto-expunge=On of Gmail's setting, mail of UID=xxx in Inbox automatically disappears.
> By (c), new mail of UID=unknown appears in TrashX.
What kind of problem can occur by above?
I think problem is only "unwanted bug open by general users" for phenomenon such as "mail is still held in [Gmail]/All Mail even though I executed Empty Trash".  

Reason why "*STILL* forcing [Gmail]/Trash" is simply that;
  Developers have to resolve many other important/critical problems first.
Why developers, who are volunteer, who are never working for you, should change Tb's code to resolve never-major/never-important problem of "Still forcing [Gmail]/Trash" for you and for several peoples ASAP with highest priority?

I also think that "adding Gmail Label of TrashX by delete of mail in Tb" is very convenient as far as user well understands "to permanently delete mail from Gmail, copy or move mail to [Gmail]/Trash is needed". 
But, using IMAP delete model of "Just mark it as deleted" is a best way in IMAP use, because "delete mail in IMAP" is simply "storing \Deleted flag to mail".
There is no reason to copy deleted mail to other Mbox in IMAP concept.

"Using IMAP delete model of Just mark it as deleted" is never due to change in Tb 17.0.2.
What is reason why you can't accept "IMAP delete model of Just mark it as deleted"?
Smart Phone etc. never supports "Just mark it as deleted" like one?
Smart Phone etc. always copies deleted mail to predefined root-level Trash regardless of server type?

	Tim K Reporter
	Comment 9 • 12 years ago

To me this is a regression. What has worked a certain way for many many years cannot be changed overnight like this with a minor .2 update, without at least giving the users a way to be backwards compatible. I understand the desire to work just like Gmail which is fine, but there are many other IMAP clients out there that don't work like Gmail and they interact with Gmail just fine. At least for my use case it is more important to work like the other 3-4 IMAP clients (on phones, tablets, command line such as alpine) I use with Gmail, than to work like the Gmail web interface which I very rarely use. It's fine for TB to support 2 modes but it's not fine to take away 1 mode overnight, with a minor .2 update.

We can argue about this until the end of time, I made my point, the devs will make a decision one way or another and I will have to adjust accordingly. Thank you.

	WADA:World Anti-bad-Duping Agency
	Comment 10 • 12 years ago

(In reply to Tim K from comment #9)
> At least for my use case it is more important to work like the other 3-4 IMAP clients
> (on phones, tablets, command line such as alpine)
> I use with Gmail, than to work like the Gmail web interface which I very rarely use.

If so, overwriting of nsIMsgIncomingServer.isGmailServer property by addon may be a short term workaround in your case.
(1) Restart Tb with IMAP delete model == "Move to trash".
    Open folder of Gmail IMAP account(force login for capability).
    => [Gmail]/Trash is used as trash. trash folder selection is ignored.
(2) Get IncomingServer object for the Gmail IMAP account.
(3) If(IncomingServer.type=="imap"&&IncomingServer.isGmailServer==true)
    IncomingServer.isGmailServer=false;
(4) Change trash selection to [Gmail]/Trash in order to force
    "trash folder selection at Server Setting" == "trash folder used by Tb".
    End Account Settings => trash-can-icon of [Gmail]/Trash is removed.
    (no special folder of "Trash" in this account at this stage) 
(5) Change back IMAP delete model to "Move to trash".
    Change trash selection to TrashX.
    End Account Settings => icon of TrashX is changed to trash-can-icon.
(5) After it, Tb 17.0.2 copied mail to the TrashX when delete of mail is executed.

Because "capability response" is returned to each login to server, mechanism to detect "isGmailServer status change by Tb" is perhaps required. Removal of "special folder of Trash flag of [Gmail]/Trash" by addon may be needed additionally. "getting mail.server.serverN.trash_folder_name value(call TrashX)", "settting 'special folder of Trash flag' to TrashX folder may be needed additionally.

	WADA:World Anti-bad-Duping Agency
	Comment 11 • 12 years ago

When "Move to trash model" && trash==TrashX, if IncomingServer.isGmailServer==false is set and SpecialUse flag of Trash is cleared at [Gmail]/Trash and SpecialUse flag of Trash is set at TrashX, "dDelete" moves mails to Trash for a while(not so short period), although Trash flag of TrashX is removed suddenly and Trash flag of [Gmail]/Trash is set suddenly, and although IncomingServer.isGmailServer==true is set suddenly. (it doesn't look done upon every server login at multiple connections.)

With "Move to trash model" && trash==TrashX, if IncomingServer.isGmailServer==false is not intentionally set, even when SpecialUse flag of Trash is set in TrashX folder and SpecialUse fla of Trash is removed from [Gmail]/Trash by addon, the flag is removed immediately by Tb while doing ordinal operation such as folder switch.
This is same as phenomenon when trash folder selection is changed at Server Settings UI.

So, I guess that SpecialUse flag change by Tb is done upon each folder open like event, and I guessed that setting isGmailServer==true is done upon each login which processes CAPABILTY response.

My guess doesn't seem so bad.
> http://mxr.mozilla.org/comm-central/source/mailnews/imap/src/nsImapProtocol.cpp#1511
>  1511 bool nsImapProtocol::ProcessCurrentURL()
>  1716       FindMailboxesIfNecessary();
> http://mxr.mozilla.org/comm-central/source/mailnews/imap/src/nsImapProtocol.cpp#7060
>  7060 void nsImapProtocol::FindMailboxesIfNecessary()
>  7075     DiscoverMailboxList();
> http://mxr.mozilla.org/comm-central/source/mailnews/imap/src/nsImapProtocol.cpp#7191
>  7191 void nsImapProtocol::DiscoverMailboxList()
>  7340   MailboxDiscoveryFinished();
> http://mxr.mozilla.org/comm-central/source/mailnews/imap/src/nsImapProtocol.cpp#7388
>  7388 void nsImapProtocol::MailboxDiscoveryFinished()
>  7441       m_imapServerSink->DiscoveryDone();
> http://mxr.mozilla.org/comm-central/source/mailnews/imap/src/nsImapIncomingServer.cpp#1425
>  1425 NS_IMETHODIMP nsImapIncomingServer::DiscoveryDone()
>
>  1513             if (trashFolder)
>  1514             {
>  1515               // if we're a gmail server, we clear the trash flags from folder(s)
>  1516               // without the kImapXListTrash flag. For normal servers, we clear
>  1517               // the trash folder flag if the folder name doesn't match the
>  1518               // pref trash folder name.
>  1519               bool clearFlag;
>  1520               if (isGMailServer)
>  1521               {
>  1522                 nsCOMPtr<nsIMsgImapMailFolder> imapFolder(do_QueryInterface(trashFolder));
>  1523                 int32_t boxFlags;
>  1524                 imapFolder->GetBoxFlags(&boxFlags);
>  1525                 clearFlag = !(boxFlags & kImapXListTrash);
>  1526               }
>  1527               else
>  1528               {
>  1529                 nsAutoString folderName;
>  1530                 clearFlag = (NS_SUCCEEDED(trashFolder->GetName(folderName))) &&
>  1531                  !folderName.Equals(trashName);
>  1532               }
>  1533               if (clearFlag)
>  1534                 trashFolder->ClearFlag(nsMsgFolderFlags::Trash);
>  1535             }

It was perhaps done due to many unwanted bug open by general users, instead of "due to critical problems around trash folder selection".

"Forcing [Gmail]/Trash" is better for majority of general users. However, I believe "Prohibiting other than [Gmail]/Trash" is never correct action.
I believe above "Forcing [Gmail]/Trash when isGMailServer==true" should be optional.

	WADA:World Anti-bad-Duping Agency
	Comment 12 • 12 years ago

"Why forcing [Gmail]/Trash was needed" is perhaps;
- Default trash folder name in Tb == Trash.
  "Gmail IMAP or not" is known only after successfull login.
  => after account creation, setting at Server Settings is trash==Trash.
- If Trash doesn't exist at server, Tb requests creation of root-level Trash.
  => Gmail Label of [Imap]/Trash is created by Gmail, as you know.
=> Useless bugs for "wrong [Imap]/Trash", "Empty Trash won't delete mail from Gmail", ..., were opened. (flood of useless bugs is sufficiently critical problem for developers and QA peoples :-)

	WADA:World Anti-bad-Duping Agency
	Comment 13 • 12 years ago

Correct solution is perhaps bug 800035 comment #2.
However, as for "trash selection at Server Settings", I think new prefs like mail.server.serverN.force_Gmail_Trash_if_is_gmail_true(deault=true) and following change is an easiest/simplest quick solution.
> 1520 -      if (isGMailServer)
> 1520 +      if (isGMailServer && force_Gmail_Trash_if_is_gmail_true)

	WADA:World Anti-bad-Duping Agency
	Comment 14 • 12 years ago

Test extension simply does following only.
  If selected account at folder pane is IMAP server,
  and if selected folder at folder pane is not "Inbox" && not special folder,
  set SpecialUse==Trash flag to the selected folder,
  and clear SpecialUse==Trash flag of all oher folder if it has it.

How to use.
(1) Install test extesion(named WinBackMyTrash), restart Tb, costomize ToolBar,
    add button(named WinBackMyTrash1) to Menu Bar.
(2) Open Error Console.
(3) Select a folder of any IMAP account
(4) Click the button.

If Gmail IMAP, following is observed.
(A) By button click, trash-icon of [Gmail]/Trash is removed,
    icon of selected folder(call TrashX) is changed to trash-can-icon,
    "Empty Trash" context menue is added to the selecte folder.
(B) Until "Trash==[Gmail]/Trash" is forced by Tb again, "Delete" moves mail to TrashX.
(C) Folder switch doesn't force "Trash==[Gmail]/Trash", because "Forcing Trash==[Gmail]/Trash" is done in folder discovery.
(D) By collapse/expand of account, by Subscribe/Unsubscribe operation, by folder creation(may be deletion too), "Trash==[Gmail]/Trash" is forced again by Tb.

This indicates culprit is nsImapIncomingServer::DiscoveryDone().

Action by the test extension is a workaround of following problem.

When "trash selection at Server Settings" == "folder which is actually used as trash by Tb(usually [Gmail]/Trash", if IMAP delete model is changed to "Just mark it as deleted" or "Remove immediatelly", Tb removes Trash flag from [Gmail]/Trash. After it, no trash folder exists in this IMAP account, so no folder has context menu of "Empty Trash".
However, File/Empty menu is not disabled. So, if File/Empty Trash is executed and OK is replied, following exception occurs(known phenomenon).
> Error: An error occurred executing the cmd_emptyTrash command:
> [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIMsgFolder.emptyTrash]"
>  nsresult: "0x80004005 (NS_ERROR_FAILURE)"
>  location: "JS frame :: chrome://messenger/content/folderPane.js :: ftc_emptyTrash :: line 2221"  data: no]
> Source File: chrome://global/content/globalOverlay.js Line: 95

If a folder is set as SpecialUse=Trash folder, Context menu of "Empty Trash" is enabled by Tb, so File/Empty Trash works well too.

Other oberved phenomena.

(i) I looks that no one generates incomingServer.trashFolderName property and incomingServer.isGMailServer property in recent Tb. "undefined" is returned always, if newly creatd account by Tb 17.0.2.
If "storing data to this property" is attempted, exception occurs.

(ii) When I tested with old profile(sever_name.msf for incomingServer.rootFolder was creatd by old Tb), incomingServer.trashFolderName property and incomingServer.isGMailServer property could be accessed and could be modified. And when incomingServer.trashFolderName was changed, the change was immediately applied to mail.server.serverN.trash_folder_name and it was also applied to trash selection at Server Settings.
However, after some testing, including "delete of server_name.msf", I couldn't access both property.

Above indicates;
- Old Tb generated trashFolderName and isGMailServer in .msf.
- If entry for them already exists in .msf, access to them can be normally done, and code which processes the change still works as implementd in the past.
- Recent Tb doesn't generate such entry in .msf, so some of old features doesn't work any more.

As for "Gmail IMAP detection" and "internal processing of is_gmail/isGMailServer status", I belive there is no problem. However, it looks that there is no way to know is_gmail/isGMailServer except "access by C++ module" or "access by prefs data reading", and it's nearly impossible to know "what folder is actually used Tb".
These may cause problem in add-on creation.

As seen in test results by simple extension for test, even if "simply use other than [Gmail]/Trash as trash" will be achieved by small change in DiscoveryDone(), different problems may arise.
I believe correct fix of bug 800035 comment #2 is needed.

	WADA:World Anti-bad-Duping Agency
	Comment 15 • 12 years ago

FYI.

DiscoveryDone(), which does do setflag() of Trash flaag for [Gmail]/Trash(trash in XLIST) and clearflag() of Trash flag of all other folders, was invoked by expand of an account at folder pane.

> 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();

This explains phenomenon observed when account is collapsed and re-expanded.

	WADA:World Anti-bad-Duping Agency
	Comment 16 • 12 years ago

Other user, who also started to see phenomenon of bug 533140 after upgrade to Tb 17.0.2, added commet to that bug, and posted interesting comment about workaround.
  Hide Trash([Gmail]/Trash via IMAP) for IMAP in Gmail setting.
If "purge after 30 days by Gmail" can not be accepted, it's a reasonable workaround.

Anyway, closing as dup of bug 533140. If duping is wrong, re-open, please.

By the way, while I'm learning/testing icommingServer.trashFolderName for this bug, I perhaps fortunately found cause/solution of bug 480393(localized trash name)/bug 491424(namespace). Because these are actually bug(actual flaw in code of Tb), requesting early resolvig is rasonable. Because volume of change reuired to "not prohibit using other than [Gmail]/Trash as trash even if Gmail IMAP" may be achieved in fixing of problem like bug 480393/bug 491424, because "volume of changes required for this bug" is not so large(rather small) and all of them are relevant.

	ncnmra
	Comment 17 • 12 years ago

@Tim K: I completely agree and had the exact same problem (working for years, broken after 17.0.2). I use TB specifically because I *don't* wan it to work exactly like the Gmail interface. 

Cheap workaround is posted in my comment #47 here:
https://bugzilla.mozilla.org/show_bug.cgi?id=533140#c47

	Tim K Reporter
	Comment 18 • 12 years ago

Hiding [Gmail]/Trash is not even a cheap workaround for me, I rely on both Trash and [Gmail]/Trash being visible because I use both Delete and Shift-Delete and sometimes need to recover or refer to something that I sent to [Gmail]/Trash.

To me this is a regression and not a duplicate of bug 533140 that has been open forever. I doubt 533140 will be addressed in the next 17.x TB update, but this regression should be addressed quickly, please.

It is not acceptable to take away functionality that people relied on since the early days of TB in a minor .2 version update.

	WADA:World Anti-bad-Duping Agency
	Comment 19 • 12 years ago

(In reply to Tim K from comment #18)
> because I use both Delete and Shift-Delete (snip)

Why can "Delete or Shift+Delete" is relevant to issue? Read bug 533140 comment #54, please.
Are you talking something related to difference around "Undo Delete" between "Delete" and "Shift+Delete"?

FYI.
If [Gmail]/All Mail, "Undo delete" is always meaningless, because Gmail doesn't save \Deleted flag for [Gmail]/All Mail.
\Deleted flag is held always only for [Gmail]/Trash and [Gmail]/Spam by Gmail.
If Gmail IMAP with auto-expunging=On, "Undo delete by uid xxx store -Flag \Deleted" is meaningless in restoring Gmail Label, because Gmail Label is removed from "mail flagged as \Delete" and the mail is immeiately expunged at correspnding IMAP folder.

> Hiding [Gmail]/Trash is not even a cheap workaround for me, (snip)

How about "unsubscribe [Gmail]/Trash"?
See bug 533140 comment #51, #53 etc., please.
  
> To me this is a regression and not a duplicate of bug 533140 (snip)

Even if regression for you, it's merely phenomenon of "Tb now works correctly in Gmail IMAP detection, then Tb now works as intended, thus you can see already known phenomenon reported to bug 533140".
It's simply a current restriction for some users, who are not majority of Thunderbird general users, who can't accept "Just mark it as deleted" nor "Remove immediately" which is usually better than "Move to trash" in IMAP use, especially when Gmail IMAP because of particularity of Gmail IMAP.

By the way, check test extension named WinBackMyTrash what I attached to bug 533140, please.
Because DiscoveryDone() adds SpecialUse=Trash flag to [Gmail]/Trash only and removes SpecialUse=Trash flag from any other folder, WinBackMyTrash removes SpecialUse=Trash flag from [Gmail]/Trash and adds SpecialUse=Trash flag to currently selected folder and regiter it to trash_folder_name in prefs.js.
After it, until collapse/re-expand is executed, by which DiscoveryDone() is called, the trash folder set by WinBackMyTrash is normally used as "trash in Tb" even if Gmail IMAP.
I believe this is an evidence of that "small change in DiscoveryDone() only" is effective and sufficint to remove current restriction for some/non-majoity Tb users.

	WADA:World Anti-bad-Duping Agency
	Comment 20 • 12 years ago

Your comment in that bug.
> 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've found SpecialUse(Unused1/2/4).
Addon like next is possible.
  Add SpecialUse(UnusedN) flag to only one folder, like WinBackMyTrash does.
  Change Delete key/menu action of an Gmail IMAP account on selected mail(s) to
     "copy to SpecialUse(UnusedN)_folder" + "delete from the selected folder",
  Change Delete key/menu action of an Gmail IMAP account on selected folder to
     "copy to SpecialUse(UnusedN)_folder" + "delete the selected folder"
     == "rename .../A_folder SpecialUse(UnusedN)_folder/A_folder"
Because delete logic is never changed and target folder only is changed from SpecialUse(Trash) folder to SpecialUse(UnusedN) folder, I think change by such addon is not so big.

But, I believe small change of DiscoveryDone() logic, which is culprit of current restriction, is far simpler/easier and implementation cost/workload is far low than such addon.
Can some one implement addon to change DiscoveryDone() action or overlay DiscoveryDone() logic written in C++?

	Eric Moore
	Comment 21 • 11 years ago

"It's simply a current restriction for some users, who are not majority of Thunderbird general users, who can't accept "Just mark it as deleted" nor "Remove immediately" which is usually better than "Move to trash" in IMAP use, especially when Gmail IMAP because of particularity of Gmail IMAP."

Thunderbird has over 20 million users, so a non-majority can be an awful lot of users. I strongly prefer "Just mark it as deleted" but I've noticed one reason some people prefer to use "Move it to trash" is because it gives them a chance to second guess deleting a message. My father for example will wait until several hundred messages accumulate in the Trash folder and then review each of them, and empty the trash. I had him try using "Just mark it as deleted" for a week but he hated it because it forces him to change how he likes to work. He's been using IMAP accounts for almost a decade.

I also periodically run into users in the support forums that are "forced" to use IMAP for some reason (the new account wizard defaulted to IMAP for Gmail and they're not comfortable fixing that after the account was created, they are using an account at work that only supports IMAP.....), that find it very useful to make the IMAP account emulate a POP account (by using Move it to Trash, message filters to move messages to a inbox in Local Folders etc) because POP accounts are what they are comfortable with. Its a big deal to them.

	Wayne Mery (:wsmwk)
	Comment 22 • 11 years ago

(did not intend to set status unconfirmed)

(In reply to WADA from comment #20)
> 
> I've found SpecialUse(Unused1/2/4).
> Addon like next is possible.
>   Add SpecialUse(UnusedN) flag to only one folder, like WinBackMyTrash does.
>   Change Delete key/menu action of an Gmail IMAP account on selected mail(s)
> to
>      "copy to SpecialUse(UnusedN)_folder" + "delete from the selected
> folder",
>   Change Delete key/menu action of an Gmail IMAP account on selected folder
> to
>      "copy to SpecialUse(UnusedN)_folder" + "delete the selected folder"
>      == "rename .../A_folder SpecialUse(UnusedN)_folder/A_folder"
> Because delete logic is never changed and target folder only is changed from
> SpecialUse(Trash) folder to SpecialUse(UnusedN) folder, I think change by
> such addon is not so big.
> 
> But, I believe small change of DiscoveryDone() logic, which is culprit of
> current restriction, is far simpler/easier and implementation cost/workload
> is far low than such addon.
> Can some one implement addon to change DiscoveryDone() action or overlay
> DiscoveryDone() logic written in C++?