Closed Bug 1175446 Opened 9 years ago Closed 5 years ago

38.0.1, If [Gmail]/Trash is hidden at Gmail or unsubscribed by user, Trash flag of all folders is cleared, so no folder has "trash can icon", then "delete mail with move to trash model" silently skips "copy to trash" step and simply storess \Deleted flag

Categories

(MailNews Core :: Networking: IMAP, defect)

Product:
MailNews Core
Component:
Networking: IMAP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(thunderbird_esr6869+ fixed, thunderbird70 fixed)

Status:
RESOLVED FIXED
Milestone:
Thunderbird 70.0
Tracking Flags:
Tracking Status
thunderbird_esr68 69+ fixed
thunderbird70 --- fixed

People

(Reporter: kees.middelburg, Assigned: gds)

References

(Depends on 1 open bug)

Details

(Keywords: regression, Whiteboard: [regression:Tb38][key comnment 67])

User Story

[Steps to Reproduce],
based on Benjamin's description/explanation about phenomenon/problem.
0. Setups
   Gmail's Label setting (Display Language=English(US) case) :
     Trash : 'Shown in IMAP' = UNTICKED in gmail settings
     => [Gmail]/Trash is not returned to any of XLIST, LIST, LSUB
   Because [Gmail]/Trash is hidden by Gmail,
   setting of "Show only subscribed folders" is irrelevant to issue.
   If "Unsubscribe [Gmail]/Trash", [Gmail]/Trash is returned to XLIST, LIST,
   and [Gmail]/Trash is not returned to LSUB.
   So, "Show only subscribed folders" is needed.
   IMAP delete model = Move to trash
   mail.server.server#.trash_folder_name = AAA
   View/Folders/All, No automatic new mail check.
   Before termination of Tb, select account at folder pane,
   in order to avoid automatic folder open(server access).
1. Restart Tb, Open Inbox
   => Trash attribute is not set in any folder,
      so no folder has "trash can icon".
2. Collapse/Expand Gmail IMAP account at Folder Pane
   "trash can icon" is shown for top level AAA folder at folder pane,
   then the "trash can icon" of AAA folder quickly disappears.
   => No folder has Trash attribute, no folder has "trash can icon"
3. Store Trash atrribute in top level BBB folder by my test addon
   => "trash can icon" is shown for the BBB folder.
      I didn't check delete mail operation, but it should work.
4. Collapse/Expand Gmail IMAP account at Folder Pane
   => No folder has Trash attribute, no folder has "trash can icon"

Note-1:
If [Gmail]/Trash is not hidden by user, [Gmail]/Trash exists in Tb, so Trash attribute is stored in [Gmail]/Trash, and "trash can icon" is shown for [Gmail]/Trash, and "[Gmail]/Trash" is used by "Delete mail" as "Move target folder of Delete Mail operation".
Note-2:
Following is already known phenomenon in other bug(s).
  If there is no folder of "trash can icon" under IMAP account,
  "Delete mail with Move to trash model" silently does do "uid store xx +Flags(\Deleted)" only,
  even though "uid copy(or move) xx trash-in-Tb" fails or impossible
  where trash-in-Tb here == first founf folder which has Trash attribute.
In contrast to it, if local mail folder account(POP3, Local Folders),
"trash folder name in Tb" is hard coded as "Trash", and "no trash can icon folder"==no folder named "Trash". So, if "no trash can icon folder", "Delete mail" does do nothing, with no error message nor feedback to user. This is also known phenomenon.

Attachments

(1 file, 2 obsolete files)

1175446-review-changes-v0.patch
(deleted), patch
mkmelin
: review+
jorgk-bmo
: feedback+
jorgk-bmo
: approval-comm-esr68+
Details | Diff | Splinter Review
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0 Build ID: 20150525141253 Steps to reproduce: 1. I deleted a message from my Inbox while the server setting was to move it to the IMAP trash folder (named Trash). 2. I looked in the Inbox and the message was no longer there. 3. I looked in the IMAP trash folder (the special icon was gone) and it was empty. Actual results: When I deleted the message, it was removed immediately. Expected results: The message should have been moved to the IMAP trash folder.
> 3. I looked in the IMAP trash folder (the special icon was gone) and it was empty. Great detailed report. The key is the icon, which indicates Thunderbird does not recogonize it as THE trash folder. Did you install Thunderbird as a non-english locale/language?
Flags: needinfo?(kees.middelburg)
I did install the english version (en-US). By the way, the trash icon is visible for at most a second when the Thunderbird window opens at the start-up of Thunderbird.
Flags: needinfo?(kees.middelburg)
Does functionality return, if you downgrade to 31.7.0 from https://ftp.mozilla.org/pub/mozilla.org/thunderbird/releases/31.7.0/win32/en-US/ ?
Component: Untriaged → Networking: IMAP
Flags: needinfo?(kees.middelburg)
Product: Thunderbird → MailNews Core
Yes, the correct functionality returns (but now Lightning 4.0.0.1 is incompatible and an older version of Lightning seems no longer available).
Flags: needinfo?(kees.middelburg)
Thanks for checking that. Please reinstall 38 from https://www.mozilla.org/en-US/thunderbird/ With 38, can you please get a very short protocol log please with setting of "imap:5"? see https://wiki.mozilla.org/MailNews:Logging
Summary: From version 38.0.1, when I delete a message, it is removed immediately instead of moved to the IMAP trash folder → 38.0.1, when I delete a message it is removed immediately instead of moved to the IMAP trash folder, because Trash folder has lost it's specialness
Whiteboard: [regression?]
I opened Thunderbird, deleted the last received message, and closed Thunderbird. Even in this case, the log is too long to put in a comment (perhaps because I use two email accounts (the problem is only with the gmail account)). What should I do now?
You can attach the file using the "add an attachment" link on the top of this page.
The session: 1. Opening of Thunderbird; 2. Deletion of last received message (from postbode@emv.hallmark.nl); 3. Closing of Thunderbird.
Same behavior seen here. Deleting messages on GMAIL via IMAP which should move the message to a trash folder is now completely inoperable as per Kee's description. Happy to provide additional logs if useful.
Same behavior also for me, using GMAIL via IMAP. The functionality (ability to select another folder for trash) worked in 31.7 provided I was not subscribed to [Imap].Trash or Trash folders. With 38.01, the selected folder looses the icon, although it has it for about a second when Thunderbird starts, as reported by Kees in Comment #1. Btw., the deleted messages are in All-Mail, but they have no label. Also, it is not possible to remove folders. If I use FolderFlags extension, I can make the selected trash folder work as desired. The folder has the icon, messages are moved there when deleted, and folders can be deleted. However, after Thunderbird restart the icon is reset and functionality lost.
Have noticed this today with 2 PCs after upgrading to 38.0.1 (also Gmail/IMAP). Managed to temporarily revert to our normal operation by changing the behaviour to 'just mark it as deleted' and closing the client. Upon reopening and reverting the setting to select the 'Deleted' folder again, the functionality and the special folder icon returns. I noted that the folder name changes temporarily to 'Trash' instead of Deleted. However when the client closed again, the folder loses the special functionality again and we’re back to the. The only difference is that my deletions are going now going directly to the ‘bin’ folder on Gmail, this could be because I have the ‘Clean up inbox on exit’ setting.
(In reply to Kees Middelburg from comment #8) > Created attachment 8624071 [details] > imap.log log of session in which message is deleted just before closing > > The session: > 1. Opening of Thunderbird; > 2. Deletion of last received message (from postbode@emv.hallmark.nl); > 3. Closing of Thunderbird.
Flags: needinfo?(m-wada)
Attachment #8624071 - Attachment mime type: text/x-log → text/plain
Flags: needinfo?(m-wada)
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #12) Flags: needinfo?(m-wada@usa.com) What do you want? Looking into log? If so, which part is relevant to problem of this bug in which comment or which phenomenon? Which part is Tb's fault? Please note that log is merely for "what command Tb issued" only. Without "when, what did user do on which UID", and "when, what is shown/done by Tb on wich UID", etc., noyhing can be said on log. - If user deleted UID=abc, but Tb requested "delete of UID=xyz" to server, we can say "Tb is wrong". But log of "delete request for UID=xyz to server" only is merely "Tb requested delete of UID=xyz". - When user deleted UID=abc at 09:00:00, but Tb requested it to server at 23:00:00, we can say Tb is funny. But "log only" merely says "Tb requested to server at 23:00:00" only.
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #12) > (In reply to Kees Middelburg from comment #8) > > Created attachment 8624071 [details] > > imap.log log of session in which message is deleted just before closing > > The session: > > 1. Opening of Thunderbird; > > 2. Deletion of last received message (from postbode@emv.hallmark.nl); > > 3. Closing of Thunderbird. (a) Log for "\Deleted flag store" is following. imap.gmail.com:S-INBOX:SendData: 27 uid store 14402 +Flags (\Seen \Deleted) So, I can guess: "Deletion of last received message" was done at Inbox of Gmail IMAP account. But I'm not sure, because nothing is stated. (b) Log for copy/move to trash is not seen. But "what imap delete model was set when the log was taken" is not stated, so I can say nothing about "it's correct Tb's behaviour or not". For following comment #10 by other than bug opener: > Same behavior also for me, using GMAIL via IMAP. The functionality (ability > to select another folder for trash) worked in 31.7 provided I was not > subscribed to [Imap].Trash or Trash folders. With 38.01, the selected folder > looses the icon, although it has it for about a second when Thunderbird > starts, as reported by Kees in Comment #1. Btw., the deleted messages are in > All-Mail, but they have no label. Also, it is not possible to remove folders. > > If I use FolderFlags extension, I can make the selected trash folder work as > desired. The folder has the icon, messages are moved there when deleted, and > folders can be deleted. However, after Thunderbird restart the icon is reset > and functionality lost. Because user uses Gmail IMAP, this is misunderstanding on "Tb's trash folder related behavior due to particulaarity of Gmail/Gmail IMAP", and comment poster haven't read Gmail Help documents which can be called "Gmail / Gmail IMAP User's Guide", which is needed to understand particularity of Gmail/Gmail IMAP. Tb ignores "trash folder setting" if Gmail IMAP. Tb always uses "Mbox which Gmail/Gmail IMAP uses as trash folder" as trash folder in Tb when Gmail IMAP is used and imap delete model = Move to Trash is used. Purpose is: To be torelant with trash folder name in Gmail which varies, which depends on Display Language. To keep same behavior as Gmail in "Tb's Delete mail, with imap delete model=move to trash". At Gmail Web(Web mail), "Delete" is always "Move to trash of localized name in Gmail". About some comments on "trash folder icon". Regardles of "imap server is Gmail or not", when IMAP delete model != "move to trash", Tb removes special attribute of "Trash" from currently used trash folder. This is to provide way to delete/rename folder named Trash when "IMAP delete model != move to trash". For following in comment #0. > Steps to reproduce: > 1. I deleted a message from my Inbox while the server setting was to move it to the IMAP trash folder (named Trash). > 2. I looked in the Inbox and the message was no longer there. > 3. I looked in the IMAP trash folder (the special icon was gone) and it was empty. It sounds for me : "IMAP trash folder (the special icon was gone)" == root level "Trash" in Tb and Gmail IMAP == [Imap]/Trash in Gmail Web(Gmail Label) == trash folder set in Tb's Server Settings (default is root level "Trash" in Tb) i.e. If IMAP delete model==move to trash, he looked [Imap]/Trash of Gmail Web(Gmail Label) at step 3. If IMAP delete model!=move to trash, he doesn't understand "IMAP delete model!=move to trash in Tb" at step 3.
FYI. Following is imap log for "geting special folder name used in Gmail". 7 xlist "" "%/%" * XLIST (\HasNoChildren \AllMail) "/" "[Gmail]/All Mail" * XLIST (\HasNoChildren \Spam) "/" "[Gmail]/Spam" * XLIST (\Trash \HasNoChildren) "/" "[Gmail]/Trash" 7 OK Success - Mbox of \AllMail attribute = [Gmail]/All Mail in Gmail IMAP (== All Mail in Gmail Web)~ - Mbox of \Spam attribute = [Gmail]/Spam in Gmail IMAP (== Spam in Gmail Web)~ - Mbox of \Trash attribute = [Gmail]/Trash in Gmail IMAP (== Trash in Gmail Web)~ "/Trash" part in "[Gmail]/Trash" varies by/depends on "Display Language of Gmail Web". /Trash, /Bin, /ゴミ箱, /Papierkorb, ... Because Tb currently always uses "special Mbox of \Trash attrbute which is used by Gmail" as Tb's special folder of Trash attribute, even if user changed Display Language at Gmail, Tb can always use "trash folder used by Gmail Web" as "trash folder in Tb". If this is not done, user has to change "trash folder setting at Server Settings" upon each Display Laanguage Change. If this is not done, all "Display Language=non-English(US)" users have to set "trash folder setting at Server Settings of Tb" before starting to use Gmail IMAP accout in Tb. This is reason why Tb always uses "special Mbox of \Trash attrbute which is used by Gmail" as "trash folder in Tb" regardless of "trash folder setting in Server Settings of Tb".
To bug opener and problem reporters in this bug. Please surely rule out "mismatch between your expectation and Tb's current behavior" and "your misunderstanding about particularity of Gmail/Gmail IMAP" from your problem report in this bug.
FYI. See Bug 533140 for request of "custom trash folder use even when Gmail IMAP". Bug 533140 - Cannot specify custom trash folder using Gmail IMAP ([Gmail]/Trash is always used regardless of trash folder selection at Server Settings, because Tb currently ignores trash folder selection if Gmail IMAP in order to avoid unwantedd problems)
For following part in bug summary. > "when I delete a message it is removed immediately" It's pretty normal phenomenon if Gmail IMAP is used with Auto-Expunge=On(default is On). When \Deleted is stored via Gmail IMAP, Gmail immediately removes Gmail Label added to the mail. This can be seen pretty easily by; IMAP delete model = Just mark it as deleted Shift+Delete of mail(s) at a Gmail Label(Inbox, YourFolderA, YourFolderB, ...) (Shift+Delete == simply store \Deleted without copy to trash even when "move to trash" model) Mails are shown with strike-thru line, with "Deleted" indicator Click other folder, then clck the folder again => mails disappear, because Auto-Expunge works.
For following in comment #0. > Steps to reproduce: > (named Trash). Because Tb shows bottom part only at trash setting of Server Settings, 　 "Trash" is shown for any of root level Trash, [Gmail]/Trash, ABC/Trash, ABC/DEF/Trash, ... we can not know "what folder is actually set in your environment" by your "(named Trash)” only. To know actual setting, content of mail.server.server#.trash_folder_name should be checked, and it should be shown to developers for effective/proper problem analysis. Without correct information about environment where problem occurred, no one can do correct problem analysis. I think such not-clear explanation ablout phenomenon, not-clear description about setting etc,, is a reason of chaos in this bug. If you clearly stated about "what folder do you call by IMAP trash folder", and if you clealy stated about "what folder did you saw at step 3 in comment #0", and if you cleaarely stated about which is trash setting at Server Setting, Move to Trash, Remove it immediately, Just mark it as deleted, and if you stated/answered about "trash can icon is not shown at which folder" and about "trash can icon is shown at which folder", and if you show mail.server.server#.trash_folder_name is Trash instead of [Gmail]/Trash or other, I believe QA peoples could quickly guess that mail was moved to [Gmail]/Trash in comment #0. To bug opener : Is my guess of "mail was moved to [Gmail]/Trash in comment #0" wrong?
(In reply to Reporter from comment #10) > The functionality (ability to select another folder for trash) worked in 31.7 > provided I was not subscribed to [Imap].Trash or Trash folders. > With 38.01, the selected folder looses the icon, although it has it for about a second when Thunderbird starts, (snip) >(snip) > If I use FolderFlags extension, I can make the selected trash folder work as desired. >(snip) > However, after Thunderbird restart the icon is reset and functionality lost. All phenomena you saw is described in bug 533140 comment #49. Even if you changed "folder of Trash attribute in Tb" to other than [Gmail]/Trash and it could be temporarily used as "trash folder in Tb" for a while, (folder used as trash by Delete/Empty Trash is folder which has Trash attribute in Tb) if Gmail IMAP, upon folder re-discovery(executed at least when account collapse/expand), "folder of Trash attribute && trash in Tb" is always changed back to "special Mbox of \Trash attribute which is used by Gmail" only, [Gmail]/Trash only if Display Language=Englush(US). This is current design/implementation to protect users from problems due to particularity of Gmail/Gmail IMAP, as stated in bug 533140. In Tb 38, "a while" in "temporarily could be used as trash in Tb for a while" is perhaps shorter than Tb 31, because some problems in "refreshing folder pane display upon some events" is resolved between Tb 31 and Tb 38. Problem like, when Drafts is manually created, localized Drafts name is not shown. when imap folder is renamed, it's not reflected to Folder pane immediately. > provided I was not subscribed to [Imap].Trash or Trash folders. As stated in bug 533140, (a) "Don't show [Gmail]/Trash via IMAP" and (b) "Unsubscribe [Gmail]/Trash" is a way to use "other than [Gmail]/Trash" as trash in Tb. If both (a) and (b) is surely done by you, Tb can't know about "special Mbox of \Trash attribute which is used by Gmail", and because Tb can't know about [Gmail]/Trash, it doesn't exist in IMAP server for Tb, so it's impossible to use [Gmail]/Trash. What folder or Mbox in Tb/Gmail IMAP or Gmail Label in Gmail do you call by "not subscribed to [Imap].Trash or Trash folders"? Anyway, your "using other than [Gaail]/Trash as trash in Tb" is absolutely different problem/issue from "[Gmail]/Trash is used even though mail.server.server#.trash_folder_name=Trash is set by default, then user confused". It's already processed as bug 533140. Please add comment to appropriate bug.
For localized special folder name in localized Tb and in Gmail with Display Language. bin, Trash, trash, Deleted, [Imap].Trash etc, are seen in comments. Both Tb and Gmail has "Localized Name". - Localized Tb has localized name for special folder of Inbox, Trash, Sent, Drafts, Templates, Junk, Outbox etc. - Gmail changes Gmail's special folder name according to Display Languge setting. via Gmail IMAP : [Gmail]/All Mail, [Gmail]/Trash, [Gmail]/Sent Mail, [Gmail]/Drafts, [Gmail]/Spam etc. at Gmail Web : All Mail, Trash, Sent Mail, Drafts, Spam etc. (Note: even when Inbox at Gmail is changed to localized name, Inbox in IMAP is always Inbox(case insensitive). - Gmail uses special Gmail Label for non-localized special top level folder name used by IMAP client, top level folder at IMAP client and via Gmail IMAP : Trash, Sent, Drafts, ... special Gmail Label at Gmail Web for such folder : [Imap]/Trash, [Imap]/Sent, [Imap]/Drafts, ... This easily produces confusion if localized Tb is used and/or if Display Languge=Non Englsh(US) is used. If you use localized Tb, or if use Display Language other than English(US), please clearly state about "folder name or string for folder name at where", instead of unclear "IMAP trash folder" like term, with clearly stating about "which localized version of Tb" and "which Display Language in Gmail". If you say "Trash at Folder Pane", peoples usually can think it's "top level Trash folder at Folder Pane of Tb" === "Gmail Label of [Imap]/Trash in Gmail Web". And please avoid translating by you, because "Bin" or "bin" is used for Trash in English(US) by Display Languge=English(UK) although others are same as English(US).
To bug opener: Following is your initial bug summary, ("38.0.1" in current bug summary comes from it) > From version 38.0.1, when I delete a message, it is removed immediately > instead of moved to the IMAP trash folder Does your "From version 38.0.1" mean that your problem started to occur from Tb 38.0.1? If so, what is previous version before your upgrade to Tb 38.0.1? Question again(see coment #19, please) Is my guess of "mail was moved to [Gmail]/Trash in comment #0" wrong? Questions about your comments. You say "installed un-US". Which loalized version did you/do you use? You say "correct functionality returns by installing Tb 31.7.0" (comment #4). What do you call by "correct functionality"? What string did you set/do you set in mail.server.server#.trash_folder_name? Questions about your imap log. When you got the imap log, your problem occurred? Or not occurred? When you got the imap log, which imap delete model did you use? (in comment #0, you say "server setting was to move it to the IMAP trash folder (named Trash)") Following is all LIST/LSUB/XLIST response from Gmail IMAP server in your log. Which folder do you call by "IMAP trash folder" or "(named trash)" > * LIST (\HasChildren \Noselect) "/" "[Gmail]" > * LIST (\HasNoChildren \All) "/" "[Gmail]/All Mail" > * LIST (\HasNoChildren \Junk) "/" "[Gmail]/Spam" > * LIST (\HasNoChildren) "/" "Drafts" > * LIST (\HasNoChildren) "/" "INBOX" > * LIST (\HasNoChildren) "/" "Junk" > * LIST (\HasNoChildren) "/" "Sent" > * LIST (\HasNoChildren) "/" "Trash" > * LIST (\Trash \HasNoChildren) "/" "[Gmail]/Trash" > > * LSUB (\HasChildren \Noselect) "/" "[Gmail]" > * LSUB (\HasNoChildren \All) "/" "[Gmail]/All Mail" > * LSUB (\HasNoChildren \Junk) "/" "[Gmail]/Spam" > * LSUB (\HasNoChildren) "/" "Drafts" > * LSUB (\HasNoChildren) "/" "INBOX" > * LSUB (\HasNoChildren) "/" "Junk" > * LSUB (\HasNoChildren) "/" "Sent" > * LSUB (\HasNoChildren) "/" "Trash" > > * XLIST (\HasChildren \Noselect) "/" "[Gmail]" > * XLIST (\HasNoChildren \AllMail) "/" "[Gmail]/All Mail" > * XLIST (\HasNoChildren \Inbox) "/" "Inbox" > * XLIST (\HasNoChildren \Spam) "/" "[Gmail]/Spam" > * XLIST (\HasNoChildren) "/" "Drafts" > * XLIST (\HasNoChildren) "/" "Junk" > * XLIST (\HasNoChildren) "/" "Sent" > * XLIST (\HasNoChildren) "/" "Trash" > * XLIST (\Trash \HasNoChildren) "/" "[Gmail]/Trash" Because pretty clean folder structure, I think it's top level Trash at folder pane of Tb. How could you use "top level Trash at folder pane of Tb" as "trash in Tb" eve thugh Gmail IMAP? By addon? If so, even if "trash can icon" is set in "top level Trash at folder pane of Tb" by addon etc., I can't imagne reason why you could use it as "trash in Tb" for so long time... If you could use "top level Trash at folder pane of Tb" as "trash of Tb" in Tb 31.7.0 but it's unable in Tb 38, it may be following, - In Tb 31.7.0, addon immediately changed back "top level Trash at folder pane of Tb" as "trash in Tb" when Tb uses [Gmail]/Trash as "trash in Tb". i.e addon always wins in Tb 31. - In Tb 38, addon failes to change back "top level Trash at folder pane of Tb" as "trash in Tb" when Tb uses [Gmail]/Trash as "trash in Tb". i.e. Tb wins in Tb 38, or addon doesn't work in Tb 38. If so, it's match with report by "Reporter"... Bug 533140 comment #49 is similar test to use "other than [Gmail]/Trash" as "trash in Tb" for a while. Name of my addon for the test=WinBackMyTrash. It means "Win Back My Trash from Tb and Gmail IMAP!" :-) In Tb 38, my function for it didn't work...
Flags: needinfo?(kees.middelburg)
(In addition to comment #22) 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.
FYI. "Forcing a folder as trash in Tb by my test addon" doesn't work in Tb 38, but simple "Store/Remove Trash folder atrribute only of my test addon" still works in Tb 38, so I checked with it. 1. Tb 38.2.0. Gmail IMAP, Move to trash model, so [Gmail]/Trash is used as trash in Tb. 2. Store Trash attribute in AAA and BBB => trash can icon is set in both folder => 3 folders has trash can icon 3. Delete mail => because of "move to trash model", delete = move to a folder which has Trash attribute => mail was moved to BBB (search doesn't look Alphabetic order. folder cache is relevant?) 4. Collapse/Expand the Gmail IMAp account at folder pane => "trash can icon" of AAA and BBB is cleared. => "trash can icon" of [Gmail]/Trash is kept. If Trash attribute of [Gmail]/Trash is cleared at step 2, Trash attribute of [Gmail]/Trash is stored again at this step, and "trsh can icon" is shown for [Gmail]/Trash. This is absolutely same result as before. i.e. Tb's behavior around trash/delete mail is not so largely changed in Tb 38.
To bug opener and problem reporters except "Reporter"(he uses FolderFlags extension). How did you use "other than [Gmail]/Trash" as "folder to which deleted mail is moved" or as "folder which has trash can icon" even though Gmail IMAP account defined in Tb? By addon? or by Tool? or by ToolBar button script you made?
Summary: 38.0.1, when I delete a message it is removed immediately instead of moved to the IMAP trash folder, because Trash folder has lost it's specialness → 38.0.1, when I delete a message it is removed immediately instead of moved to the IMAP trash folder, because folder which had Trash attribute folder has lost it's specialness which was set by addon
"Reporter"'s case in Comment #10 is clear, except "Same behavior" part. > Same behavior also for me, using GMAIL via IMAP. > The functionality (ability to select another folder for trash) worked in 31.7 > If I use FolderFlags extension, I can make the selected trash folder work as desired. > The folder has the icon, messages are moved there when deleted, and folders can be deleted. > However, after Thunderbird restart the icon is reset and functionality lost. I can't find clear description in this bug about that other cases than "Repoter"'s case is same as "Repoter"'s case, although other cases seems report for "select other folder THAN [GMAIL]/TRASH for trash". To Kees Middelburg(bug opener, comment #0), Benjamin(comment #9), IPC(comment #11) : Is your problem same as "Reporter"'s case?
Flags: needinfo?(spam)
Flags: needinfo?(ipcitsupport)
(In reply to WADA from comment #26) > "Reporter"'s case in Comment #10 is clear, except "Same behavior" part. > > Same behavior also for me, using GMAIL via IMAP. > > The functionality (ability to select another folder for trash) worked in 31.7 > > If I use FolderFlags extension, I can make the selected trash folder work as desired. > > The folder has the icon, messages are moved there when deleted, and folders can be deleted. > > However, after Thunderbird restart the icon is reset and functionality lost. > I can't find clear description in this bug about that other cases than > "Repoter"'s case is same as "Repoter"'s case, although other cases seems > report for "select other folder THAN [GMAIL]/TRASH for trash". > > To Kees Middelburg(bug opener, comment #0), Benjamin(comment #9), > IPC(comment #11) : > Is your problem same as "Reporter"'s case? Yes my problem is the same as Reporters. I do not use FolderFlags or any similar extension. I am using GMAIL VIA IMAP with this configuration for many years: I have a folder called 'OLD MESSAGES' which is where I store all old incoming messages after I've finished with them in my INBOX. I have Thunderbird set up with 'When I delete a message; Move it to this folder: OLD MESSAGES'. When pushing the delete key on a message in the INBOX in TB37 the message is removed from INBOX and placed in the OLD MESSAGES folder. Doing the same in TB38 and the message is not placed in the OLD MESSAGES folder. It appears in ALL MAIL in GMAIL which is not a folder I subscribe to in TB.
Flags: needinfo?(spam)
(In reply to Benjamin from comment #27) > > Is your problem same as "Reporter"'s case? > > Yes my problem is the same as Reporters. I do not use FolderFlags or any > similar extension. I am using GMAIL VIA IMAP with this configuration for > many years: > > I have a folder called 'OLD MESSAGES' which is where I store all old > incoming messages after I've finished with them in my INBOX. I have > Thunderbird set up with 'When I delete a message; Move it to this folder: > OLD MESSAGES'. When pushing the delete key on a message in the INBOX in TB37 > the message is removed from INBOX and placed in the OLD MESSAGES folder. > Doing the same in TB38 and the message is not placed in the OLD MESSAGES > folder. It appears in ALL MAIL in GMAIL which is not a folder I subscribe to > in TB. Thanks for quick & pretty interesting report with actully used Mbox/Folder name(I couldn't know it by word such as "IMAP trash folder" in this bug...). But, I can't understand reason why mail is moved to the "OLD MESSAGES", if you actually use Gmail IMAP account in Tb... Please read my comment #24, and bug 533140 comment #4 ... imap.gmail,com? or imap.googlemail .com? What addon do you use? How did you set "trash can icon" of the "OLD MESSAGES" folder of Gmail IMAP account in Tb(==Gmail Label of "OLD MESSAGES" in Gmail Web)? Space in Gmail Label of "OLD MESSAGES" is trick? (mail.server.server#.trash_folder_name=OLD MESSAGES was workaround of bug 533140 in Tb 31?)
Flags: needinfo?(ipcitsupport)
(In reply to Benjamin from comment #27) > Doing the same in TB38 and the message is not placed in the OLD MESSAGES folder. > It appears in ALL MAIL in GMAIL which is not a folder I subscribe to in TB. Thanks again for other interesting information. If Copied or Moved to [Gmail]/Trash by your Delete Mail operation in Tb, it shouldn't appear in [Gmail]/All Mail, because, if "uid copy(or move) NNN [Gmail]/Trash" at inbox was issued by Tb, the mail shouldn't be shown in [Gmail]/All Mail. The mail should be shown in [Gmail]/Trash only because of particularity of Gmail/Gmail IMAP. So, it indicates that Tb doesn't issue "uid copy(or move) NNN [Gmail]/Trash" when your Delete Mail operation with "IMAP delete model=move to trash" && "mail.server.server#.trash_folder_name=OLD MESSAGES". (Although "uid copy/move" is not seen in imap log provided by bug opener, because "what imap delete model was used when the imap log was got" is never explained by bug opener, I can know nothing from imap log provided by bug opener...) When you saw your problem in Tb 38, was "trash can icon" shown for top level "OLD MESSAGES"? How about [Gmail]/Trash? Was there any other folder which has "trash can icon" in the Gmail IMAP account?
FYI. Quick check result. Tb 38.2.9, Gmail IMAP(imap.gmail.com), Move to trash model, mail.server.server#.trash_folder_name = "OLD MESSAGES"(no quote) or AAA, Account folder is selected when Tb is terminated. No automaic new mail check. When Tb is restarted, folder specified in mail.server.server#.trash_folder_name is shown with "trash can icon". When Inbox is clicked(lohin is done, [Gmail]/Trash==trash in Gmail is known via XLIST). => "trash can icon" of folder specified in mail.server.server#.trash_folder_name is cleared. => "trash can icon" is shown for [Gmail]/Trash only. i.e. I can't reproduce your problem. Benjamin , Do you set "Don't show [Gmail]/Trash via IMAP" in Gmail setting? If so, is [Gmail]/Trash subscribed? Unsubscribed? "Show only subscribed folder" in Server setting/Advanced? Or it's unchecked? Do you set IMAP server directory in Server Settings/Advanced of Tb?
(In reply to WADA from comment #30) > FYI. > Quick check result. > Tb 38.2.9, Gmail IMAP(imap.gmail.com), Move to trash model, > mail.server.server#.trash_folder_name = "OLD MESSAGES"(no quote) or AAA, > Account folder is selected when Tb is terminated. No automaic new mail > check. > When Tb is restarted, folder specified in > mail.server.server#.trash_folder_name is shown with "trash can icon". > When Inbox is clicked(lohin is done, [Gmail]/Trash==trash in Gmail is > known via XLIST). > => "trash can icon" of folder specified in > mail.server.server#.trash_folder_name is cleared. > => "trash can icon" is shown for [Gmail]/Trash only. > i.e. I can't reproduce your problem. Hi, thanks for taking your time on this! > Do you set "Don't show [Gmail]/Trash via IMAP" in Gmail setting? YES. The tickbox is called 'shown in IMAP', it is UNTICKED in gmail settings. > If so, is [Gmail]/Trash subscribed? Unsuscribed? "Show only subscribed folder" in Server setting/Advanced? Or it's unchecked? It doesn't show up in Thunderbird subscription box at all because of the above gmail setting. So in Thunderbird I see no [GMail]/Trash folder in the subscribe dialogue box. > Do you set IMAP server directory in Server Settings/Advanced of Tb? IMAP SERVER DIRECTORY is blank in my settings...
(In reply to WADA from comment #29) > (In reply to Benjamin from comment #27) > > Doing the same in TB38 and the message is not placed in the OLD MESSAGES folder. > > It appears in ALL MAIL in GMAIL which is not a folder I subscribe to in TB. > > Thanks again for other interesting information. > > If Copied or Moved to [Gmail]/Trash by your Delete Mail operation in Tb, it > shouldn't appear in [Gmail]/All Mail, because, if "uid copy(or move) NNN > [Gmail]/Trash" at inbox was issued by Tb, the mail shouldn't be shown in > [Gmail]/All Mail. The mail should be shown in [Gmail]/Trash only because of > particularity of Gmail/Gmail IMAP. > So, it indicates that Tb doesn't issue "uid copy(or move) NNN [Gmail]/Trash" > when your Delete Mail operation with "IMAP delete model=move to trash" && > "mail.server.server#.trash_folder_name=OLD MESSAGES". > (Although "uid copy/move" is not seen in imap log provided by bug opener, > because "what imap delete model was used when the imap log was got" is never > explained by bug opener, I can know nothing from imap log provided by bug > opener...) > > When you saw your problem in Tb 38, was "trash can icon" shown for top level > "OLD MESSAGES"? > How about [Gmail]/Trash? > Was there any other folder which has "trash can icon" in the Gmail IMAP > account? In TB38 none of my folders shows up with the trash icon. Reverting to 31.7 (sorry I said 37 by mistake above) the folder OLD MESSAGES shows up with a trash icon. Please see my answer in #31 for explanation of my lack of [Gmail]/trash folder
(In reply to WADA from comment #28) > (In reply to Benjamin from comment #27) > > > Is your problem same as "Reporter"'s case? > > > > Yes my problem is the same as Reporters. I do not use FolderFlags or any > > similar extension. I am using GMAIL VIA IMAP with this configuration for > > many years: > > > > I have a folder called 'OLD MESSAGES' which is where I store all old > > incoming messages after I've finished with them in my INBOX. I have > > Thunderbird set up with 'When I delete a message; Move it to this folder: > > OLD MESSAGES'. When pushing the delete key on a message in the INBOX in TB37 > > the message is removed from INBOX and placed in the OLD MESSAGES folder. > > Doing the same in TB38 and the message is not placed in the OLD MESSAGES > > folder. It appears in ALL MAIL in GMAIL which is not a folder I subscribe to > > in TB. > > Thanks for quick & pretty interesting report with actully used Mbox/Folder > name(I couldn't know it by word such as "IMAP trash folder" in this bug...). > But, I can't understand reason why mail is moved to the "OLD MESSAGES", if > you actually use Gmail IMAP account in Tb... Please read my comment #24, and > bug 533140 comment #4 ... > imap.gmail,com? or imap.googlemail .com? > What addon do you use? > How did you set "trash can icon" of the "OLD MESSAGES" folder of Gmail IMAP > account in Tb(==Gmail Label of "OLD MESSAGES" in Gmail Web)? > Space in Gmail Label of "OLD MESSAGES" is trick? > (mail.server.server#.trash_folder_name=OLD MESSAGES was workaround of bug > 533140 in Tb 31?) Hi, I looked at the bugs you linked me to but not sure what you wanted me to do with that information? sorry. To answer your questions: I'm using imap.googlemail.com ALL ADDONS DISABLED. I'm 100% sure the behaviour changes from TB31.7 to TB38.2 as I've described. I've gone back and forward between the two versions to confirm. I made 'Old Messages' have the trash can icon by selecting 'When I delete a message; Move it to this folder: OLD MESSAGES'. In TB31.7 this gives the folder the trash icon, in TB38.2 the icon for this is a folder, not trash. Regarding your comment about the label having space in it. It has a space in GMAIL and has a space in TB.
(In reply to Benjamin from comment #31) > > Do you set "Don't show [Gmail]/Trash via IMAP" in Gmail setting? > YES. The tickbox is called 'shown in IMAP', it is UNTICKED in gmail settings. Gotcha. I've understood why you could use "OLD MESSAGES" as "trash in Tb" even though Gmail IMAP. It's a known workaround of bug 533140. See bug 533140, please. And, your case and bug opener's case is different, but similar. bug opener's case(from imap log) : [Gmail]/Trash is returned to LIST/XLIST, but not returned to LSUB. perhaps "Show only subscribed folders" is used. your case : [Gmail]/Trash is not returned to LIST/LSUB. perhaps returned to XLIST. Tb tries to access "Gmail's trash in XLIST"==[Gmail]/Trash, but it's not in LSUB response(bug opener's case), or but it's not in LIST/LSUB response(your case), then Tb 38 fails to use folder specified in mail.server.server#.trash_folder_name?
Checked with following based on Benjamin's pretty clear description about phenomenon/problem, and I could see same phenomenon. 0. Setups Gmail's Label setting : 'Shown in IMAP' = it is UNTICKED in gmail settings => [Gmail]/Trash is not returned to any of XLIST, LIST, LSUB Because [Gmail]/Trash is hidden by Gmail, setting of "Show only subscribed folders" is irrelevant to issue. IMAP delete model = Move to trash mail.server.server#.trash_folder_name = AAA View/Folders/All, No automatic new mail check. Before termination of Tb, select account at folder pane in order to avoid automatic folder open(server access). 1. Restart Tb, Open Inbox => Trash attribute is not set in any folder, so no folder has "trash can icon". 2. Collapse/Expand Gmail IMAP account at Folder Pane "trash can icon" is shown for top level AAA folder at folder pane, then the "trash can icon" of AAA folder quickly disappears. => No folder has Trash attribute, no folder has "trash can icon" 3. Store Trash atrribute in top level BBB folder by my test addon => "trash can icon" is shown for the BBB folder. I didn't check delete mail operation, but it should work. 4. Collapse/Expand Gmail IMAP account at Folder Pane => No folder has Trash attribute, no folder has "trash can icon" It looks for me: Tb 31 : Try to store Trash attribute to [Gmail]/Trash, if Success, remove Trash attribute of all other folders. => (a) if [Gmail]/Trash is not available, Trash attribute of all other folders is not removed. Tb 38 : Remove Trash attribute of all other folders, then try to store Trash attribute to [Gmail]/Trash phenomenon is simply; => (b) if [Gmail]/Trash is available, Trash attribute is stored in [Gmail]/Trash. => (c) if [Gmail]/Trash is not available, Trash attribute is not stored in [Gmail]/Trash. I guess: When Trash attribute is stored by addon to multiple folders, if "Store Trash attribute to trash in Tb" somehow fails, in Tb 31, "multiple folders which has trash can icon" can remain due to (a). In Tb 38, this problem was resolved. Logic change of addon is needed. 1. Store Trash attribute according to user's request. 2. Upon folder event of "Trash attribute is removed from my trash folder", immediately store Trash attribute again, and remove Trash attribute from all other folders including [Gmail]/Trash to keep "one trash only". This is "Endless war to win back my Trash from Tb and Gmail IMAP" :-) As I wrote in bug 533140 comment #65, you can easiliy do such job by your Toolbar Button with small button script.
Sorry, I misunderstood following comment. (In reply to Reporter from comment #10) > If I use FolderFlags extension, I can make the selected trash folder work as desired. > (snip) > However, after Thunderbird restart the icon is reset and functionality lost. "If I use FolderFlags extension" implied "no such addon is used in daily use". To "Reporter", do you hide [Gmail]/Trash? Or Unsubscribe [Gmail]/Trash only? When "trash can icon" is set for your trash folder by addon, if you don't do collapse/expand of Gmail IMAP account at folder pane, and if you don't do "Go Work Offline/Go Work Online", how long is the "trash can icon of your trash folder" kept? Usually kept until next shutdown/restart of Tb?
Flags: needinfo?(reporter)
(In addition to comment #35) > I guess: > When Trash attribute is stored by addon to multiple folders, > if "Store Trash attribute to trash in Tb" somehow fails, > in Tb 31, "multiple folders which has trash can icon" can remain due to (a). > In Tb 38, this problem was resolved. Bingo? (who set Trash attribute of multiple folders was localized Tb though) Bug 1156669 - Trash folder duplication while using IMAP with localized TB status-thunderbird38: fixed By the change, Trash attribute of all other than Gmail/[Trash] is cleanly cleared. And, if Gmail IMAP, Tb ignores mail.server.server#.trash_folder_name and tries to use "trash used by Gmail". However, there is no "trash used by Gmail" because user intentionally hided it...
Summary: 38.0.1, when I delete a message it is removed immediately instead of moved to the IMAP trash folder, because folder which had Trash attribute folder has lost it's specialness which was set by addon → 38.0.1, when I delete a message it is removed immediately instead of moved to the IMAP trash folder, because folder of Gmail IMAP which had Trash attribute folder has lost it's specialness which was set by mail.server.server#.trash_folder_name or by addon
To Wayne, if "Gmail IMAP" is removed from bug summary, it's already known phenomenon in other bug(s). If no folder of "trash can icon"(==folder which has Trash attribute) under IMAP account, "delete message==move messages to trash" silently does do "store \Deleted flag" phase even though "copy to trash" phase failed or "copy to trash" phase is impossible. This can occur when; creation of folder specified in mail.server.server#.trash_folder_name failed or impossible. folder set in mail.server.server#.trash_folder_name is deleted at server while Tb is running. intentionally clear Trash attribute of folder(s) by Tool, Addon. (my addon for test in Bug 533140 can do this, so I checked this case in the past) To clearely state "Gmail IMAP relevant issue", I put "Gmail IMAP" in bug summary. Please correct if it's wrong.
> As I wrote in bug 533140 comment #65, you can easiliy do such job by your > Toolbar Button with small button script. The downside to this approach is I don't click a button to delete messages, I (like I guess many others) press DELETE on keyboard and have done so for years. I may be wrong but your script idea doesn't seem to address that? :)
(In reply to Benjamin from comment #39) > > As I wrote in bug 533140 comment #65, you can easiliy do such job by your > > Toolbar Button with small button script. > The downside to this approach is I don't click a button to delete messages, > I (like I guess many others) press DELETE on keyboard and have done so for > years. I may be wrong but your script idea doesn't seem to address that? :) If so, Toolbar button like next may be better. When clicked, store Trash attribute to your trash, and register eventListener for the folder. When eventListener detects "loss of Trash attribute of my trash", Anti-Tb-Gmail feature wakes up: store Trash attribute to my trash, clear Trash attribute of [Gmail]/Trash. this is start of endless war with Dark "Tb+Gmail" :-)
(In reply to WADA from comment #36) > Sorry, I misunderstood following comment. > (In reply to Reporter from comment #10) > > If I use FolderFlags extension, I can make the selected trash folder work as desired. > > (snip) > > However, after Thunderbird restart the icon is reset and functionality lost. > > "If I use FolderFlags extension" implied "no such addon is used in daily > use". > > To "Reporter", do you hide [Gmail]/Trash? Or Unsubscribe [Gmail]/Trash only? > > When "trash can icon" is set for your trash folder by addon, if you don't do > collapse/expand of Gmail IMAP account at folder pane, and if you don't do > "Go Work Offline/Go Work Online", how long is the "trash can icon of your > trash folder" kept? Usually kept until next shutdown/restart of Tb? Correct, I do not use FolderFlags with Ver. 31, I just tried it to see whether it would fix the problem in Ver. 38. Both, hiding and unsubscribing work in Ver. 31. I have an account where I hide [Gmail]/Trash, and another where I'm just unsubscribed from [Gmail]/Trash, in both cases I can select the desired trash folder. I'll upgrade to Ver. 38 and test, then report back to answer your third question.
(In reply to WADA from comment #36) > Sorry, I misunderstood following comment. > (In reply to Reporter from comment #10) > > If I use FolderFlags extension, I can make the selected trash folder work as desired. > > (snip) > > However, after Thunderbird restart the icon is reset and functionality lost. > > "If I use FolderFlags extension" implied "no such addon is used in daily > use". > > To "Reporter", do you hide [Gmail]/Trash? Or Unsubscribe [Gmail]/Trash only? > > When "trash can icon" is set for your trash folder by addon, if you don't do > collapse/expand of Gmail IMAP account at folder pane, and if you don't do > "Go Work Offline/Go Work Online", how long is the "trash can icon of your > trash folder" kept? Usually kept until next shutdown/restart of Tb? I tested the behavior in Ver. 38 with the addon. The flag (and the functionality) persists even if I collapse/expand Gmail Imap account, and if I toggle Work Offline/Work Online. The flag is only cleared (and the default GMAIL Trash folder used) if I restart TB.
Flags: needinfo?(reporter)
(In reply to Reporter from comment #42) > I tested the behavior in Ver. 38 with the addon. The flag (and the > functionality) persists even if I collapse/expand Gmail Imap account, and if > I toggle Work Offline/Work Online. The flag is only cleared (and the default > GMAIL Trash folder used) if I restart TB. Questions to avod my misunderstanding. When you did this test, is [Gmail]/Trash(if Display Language=Englis(US)) hidden by Gmail? or shown by Gmail? When you did "Collapse/Expand of Gmail IMAP account", was a folder of the Gmail IMAP accout already opened by automatic new mail check or folder selection of an Mbox at Folder Pane? (a) When server connection is not established yet after restart of Tb(i.e. no folder open after restart), Subscribe shows nothing. Shows blank Subscribe panel. This is known issue. Login looks to fail if "first login after restart Tb" is done by Subscribe. (b) My check result. When state of (a), (b-1) "trash can iccon" is shown for folder named mail.server.server#.trash_folder_name, and (b-2) "trash can iccon" is shown for "trash in Gmail Web" == [Gmail]/Trash if it's not hided by Gmail. (b-3) When state of (a), by Collapse/Expand of Gmail IMAP accout, "trash can icon" of both folder is not altered. "trash can icon" of both folder is kept. (c) "Select account before termination of Tb" && "Kill automatic new mail ceck" in procedure of comment #35 is to force the "state of (a)" in order to avoid misunderting of test result and my confusion. If click of Inbox or other Mbox is executed after restaart of Tb, state of (a) is surely cleared. If no folder is selected after restart of Tb, state of (a) is surely kept. What actual folder name do you call by "GMAIL Trash folder"? [Gmail]/Trash? (if Display Language=English(US)) Or other folder which is set in mail.server.server#.trash_folder_name?
Flags: needinfo?(reporter)
To Benjamin and "Reporter". Where, How, did you know about "Hide or Unsubscribe of [Gmail]/Trash"? If you knew about it somewhere when you experienced phenomenon of "top level Trash is not used as trsh in Tb when Gmail IMAP" long ago, and if you merely/simply did it, and if you forgot it and "why you did it" for long time, I can understand why you didn't state about "Hide or Unsubscribe of [Gmail]/Trash" until I asked you, because, as for "trash folder in Tb", there was no difference of Gmail IMAP from ordinal IMAP server for you, for long time, if [Gmail]/Trash is hidden by you. And, if you knew about bug 533140, I believe that you referred to [Gmail]/Trash since initial of your problem reporing.
Flags: needinfo?(spam)
Whiteboard: [regression?] → [regression?][by change for Bug 1156669?]
Kent James (:rkent) (Assignee of bug 1156669). I think following phenomenon is a result of mismatch between "code for Gmail IMAP" and "code for bug 1156669". "Hide/Unsubscribe of [Gmail]\Trash by Gmail IMAP user" causes loss of "trash in Tb" where "trash in Tb" == folder which has Trash attribute == folder which has "trash can icon" (1) If Gmail IMAP, Tb removes Trash attribute of all folders other than [Gmail]/Trash, and store Trash attribute in [Gmail]/Trash. But in Tb 31, if [Gmail]/Trash is hidden, mail.server.server#.trash_folder_name was effective. (2) To avoid multiple "folder of Trash attribute in an IMAP account", after patch for bug 1156669, excess Trash attribute in folders is cleanly cleared. Why "only one folder of Trash attribute under an IMAP account" is not kept after patch for bug 1156669? "No folder, ZERO folder, of Trash attribute under an Gmail IMAP account if user hide [Gmail]/Trash" was surely produced by Tb 38.
Flags: needinfo?(rkent)
User Story: (updated)
Confirming, based on test result in comment #35.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Unspecified → All
Hardware: Unspecified → All
User Story: (updated)
Perhaps Jorg can also speak to comment 45
Flags: needinfo?(mozilla)
Whiteboard: [regression?][by change for Bug 1156669?] → [regression:TB38?][by change for Bug 1156669?]
Sorry, no idea. I tested bug 1156669 on a Spanish IMAP server. We know the Gmail has its own interpretation of IMAP different from the rest of the world. There are so many options both in TB the Gmail account settings, that's it's utmost confusing. (See for example bug 618553 comment #65 and further down).
Flags: needinfo?(mozilla)
(In reply to WADA from comment #44) > To Benjamin and "Reporter". > > Where, How, did you know about "Hide or Unsubscribe of [Gmail]/Trash"? > If you knew about it somewhere when you experienced phenomenon of "top level > Trash is not used as trsh in Tb when Gmail IMAP" long ago, and if you > merely/simply did it, and if you forgot it and "why you did it" for long > time, I can understand why you didn't state about "Hide or Unsubscribe of > [Gmail]/Trash" until I asked you, because, as for "trash folder in Tb", > there was no difference of Gmail IMAP from ordinal IMAP server for you, for > long time, if [Gmail]/Trash is hidden by you. > And, if you knew about bug 533140, I believe that you referred to > [Gmail]/Trash since initial of your problem reporing. I hide the TRASH folder (either via GMail label preferences inside Gmail or by unticking in the subscribe dialogue box in TB) because it is not relevant to the way I use my mail. Gmail's built in trash folder is irrelevant for me in the same way ALL MAIL is also irrelevant. I operate with three folders on TB (and also Mail for IOS): 1) INBOX (the gmail inbox) 2) SENT ITEMS (Gmail sent items) 3) OLD MESSAGES - which as per my previous description is a permanent collection of all incoming mail I have received and removed (deleted) from my inbox. OLD MESSAGES is a gmail label. I'm just a user, I don't check bug reports etc as historically TB has been stable for me. So, hopefully to answer your question, the way I have this set up is not a 'work around' for any bug. It's how I operate my mail.
Flags: needinfo?(spam)
User Story: (updated)
[Off-Topic] (In reply to Benjamin from comment #49) > I hide the TRASH folder (either via GMail label preferences inside Gmail or > by unticking in the subscribe dialogue box in TB) > because it is not relevant to the way I use my mail. > Gmail's built in trash folder is irrelevant for me in the same way ALL MAIL is also irrelevant. > I operate with three folders on TB (and also Mail for IOS): > 1) INBOX (the gmail inbox) > 2) SENT ITEMS (Gmail sent items) > 3) OLD MESSAGES - which as per my previous description is a permanent collection of all incoming mail > I have received and removed (deleted) from my inbox. OLD MESSAGES is a gmail label. Intersting, You don't need or don't want to use [Gmail]/Trash, so you simply hided [Gmail]/Trash. Then you fortunately could use "OLD MESSAGES"(a Gmail Label) as "trash in Tb"=="Move target folder of Delete" for long time until this bug started to occur. And, "hiding [Gmail]/Trash" was/is never special action for you. If mail is removed from Inbox but the deleted mail is not found in "trash in Tb", user usually complaints or shouts "my mail is lo--st!, Tb's bu--g!" as seen in many bugs for such phenomenon. However, such complaint only comment is not seen in this bug. "Reason why such comment is not seen in this bug" is perhaps that all problem reporters in this bug could find way to Hide [Gmail]/Trash by himself == User knows or looks or checks Gmail settings and Tb's settings well by himself, and user understands about Gmail/Gmail IMAP, and such good users for Tb don't write comment of complaint only at bugzilla.mozilla.org.
Quick summary of problem reports in this bug. > Comment # Comment poster IMAP server [Gmail]/Trash mail.server.server#.trash_folder_name > > Comment #0 Kees Middelburg ??? ??? ??? > perhaps Gmail IMAP perhaps Unsubscribed perhaps "Trash" (no quote) > > Comment #9 Benjamin surely Gmail IMAP Hidden by Gmail "OLD MESSAGES" (no quote) > > Comment 10 Reporter surely Gmail IMAP Hidden by Gmail, Trash? > or Unsubscribed it sounds for me Trash is used > > Comment 11 IPC surely Gmail IMAP ??? ??? To bug opener and all problem reportes(except already clearly stated Benjamin's case) : Please fill table by actual data of your case.
(Off-Topic) (In reply to Jorg K (GMT+2) from comment #48) > that's it's utmost confusing. (See for example bug 618553 comment #65 and further down). I believe; It's not confusion of you which is caused by that Gmail's behaviour is not-so-easy-to-understand. It's confusion of you which was caused by bug opener of that bug. Phenomenon of "two drafts in the Trash" which you saw in bug 618553 comment #65, is phenomenon of bug 562748. That bug is an example of that bug opener never provides his setting etc. appropriately and merely repeats "draft mails were actually not deleted in his environment". Following were provided by bug opener after long time from bug open. Move to trash model is used. (but it's not cleaar whether "Move to trash model" was used in all cases reported by bug opener) Auto-Expunging of Gmail = Off, because he dislike Gmail's behaviour of Auto-Expunging of Gmail = On. (I believe "like or dislike an option" is irrelevant to bug report. Simply "the option is used" is sufficient) View/Folders/Unified is used. If checked with IMAP delete model = Just mark it as deleted, and if checked at Drafts in View/Folders/All or checked at each account's Drafts under Unified Folder of Drafts in View/Folders/Unified, "\Deleted flag is stored or not" is pretty quickly known by strike-thru line/Deleted indicator. However, such information is never provided by bug opener since bug open on 2010-12-11 till last comment on 2015-07-30(as of today). I knew phenomenon like next in some versions of Tb. If Virtual Folder(Saved Search Folder, Unified Folder etc.), when IMAP delete model = Just mark it as deleted, strike-thru line is not shown for "mail which has \Deleted flag in IMAP folder". Such phenomenon may depend on "delete model of first found mail in the Virtual Folder". (phenomenon like next was suspected;) (if imap folder && imap delete model=Just mark it as deleted, shown with strike-thru line,) (else if imap folder && imap delete model!=Just mark it as deleted, shown without strike-thru line, or hidden,) (else if pop3/local folder, identical to "move to trash model", so shown without strike-thru line, or hidden.) I don't know such phenoenon still occurs or not. So, I asked some questions in that bug, and answer was: > I won't have more time to provide more information on this bug, > unless a developer needs my help to debug this. > Thanks for your help. This does not require any more QA action. I can never follow such bug report at bugzilla.mozillaa.org. (bug report at bugzilla.mozilla.org? It's order on developer to help him, isn't it?) (i.e. Because I say "problem occurred in my environment", ) ( such problem surely occurs, and it's surely Tb's bug because I reported.) ( So, developers have to analyze his problem. ) (I believe that such old bug is a good example of problems in bug opener insted of in Thunderbird.) I could get pretty clear description/explanation about problem of this bug, by answers from other problem reporters in this bug, by other than bug opener. Please do your best in that bug. Good luck!
Keywords: regression
Whiteboard: [regression:TB38?][by change for Bug 1156669?] → [problem after fix of Bug 1156669?]
Whiteboard: [problem after fix of Bug 1156669?] → [problem after fix of Bug 1156669?][regression in Tb 38 over Tb 31]
What change was done by bug 1156669 on nsImapIncomingServer.cpp, > http://mxr.mozilla.org/comm-central/source/mailnews/imap/src/nsImapIncomingServer.cpp#1534 > 1534 if (NS_SUCCEEDED(GetTrashFolderName(trashName))) > 1535 { > 1536 for (uint32_t i = 0; i < numFolders; i++) > 1537 { > 1538 nsCOMPtr<nsIMsgFolder> trashFolder(do_QueryElementAt(trashFolders, i)); > 1539 if (trashFolder) > 1540 { > 1541 // If we're a gmail server, we clear the trash flags from folder(s) > 1542 // without the kImapXListTrash flag. For normal servers, we clear > 1543 // the trash folder flag if the folder name doesn't match the > 1544 // pref trash folder name. > 1545 if (isGMailServer) > 1546 { > 1547 nsCOMPtr<nsIMsgImapMailFolder> imapFolder(do_QueryInterface(trashFolder)); > 1548 int32_t boxFlags; > 1549 imapFolder->GetBoxFlags(&boxFlags); > 1550 if (boxFlags & kImapXListTrash) > 1551 { > 1552 continue; > 1553 } > 1554 } > 1555 else > 1556 { > - nsAutoString folderName; > - if (NS_FAILED(trashFolder->GetName(folderName)) || > - folderName.Equals(trashName)) > 1557 + // trashName is the leaf name on the folder URI, which will be > 1558 + // different from the folder GetName if the trash name is > 1559 + // localized. > 1560 + nsAutoCString trashURL; > 1561 + trashFolder->GetFolderURL(trashURL); > 1562 + int32_t leafPos = trashURL.RFindChar('/'); > 1563 + nsAutoCString unescapedName; > 1564 + MsgUnescapeString(Substring(trashURL, leafPos + 1), > 1565 + nsINetUtil::ESCAPE_URL_PATH, unescapedName); > 1566 + nsAutoString nameUnicode; > 1567 + if (NS_FAILED(CopyMUTF7toUTF16(unescapedName, nameUnicode)) || > 1568 + trashName.Equals(nameUnicode)) > 1569 { > 1570 continue; > 1571 } > 1572 if (numFolders == 1) > 1573 { > 1574 // We got here because the preferred trash folder does not > 1575 // exist, but a folder got discovered to be the trash folder. > - SetUnicharValue(PREF_TRASH_FOLDER_NAME, folderName); > 1576 + SetUnicharValue(PREF_TRASH_FOLDER_NAME, nameUnicode); > 1577 continue; > 1578 } > 1579 } > 1580 trashFolder->ClearFlag(nsMsgFolderFlags::Trash); > 1581 } > 1582 } > 1583 } Regardless of localied Tb or en-US Tb, if default trash folder name(==Mbox of top level "Trash" at IMAP server) is used, following is applied. actual top level Mbox name at servrt = "Trash" actual msf file name = "Trash.msf" actual offline-store file name = "Trash" mail.server.server#.trash_folder_name = string of Trash(==Trash in Trash.msf) should be set (this is design of mail.server.server#.trash_folder_name). IIUC, string in folderURL is this non-localized Mbox name at server(==Trash in Trash.msf), even in localized Tb. Folder name at Folder Pane, Folder list UI, Folder selection UI ; If en-US, "Trash" is shown. If localized Tb, <localized-name-of-Trash> is shown. If customized trash folder is selected via folder selection UI at customized trash folder setting in Server Settings panel, if loclized Thunderbird, UI wrongly sets "localized folder name" in mail.server.server#.trash_folder_name, even though actual Mbox name==Trsh part of "Trash.msf" should be set in mail.server.server#.trash_folder_name. This is known bug(Bug 480393). If Bug 480393 occurs, Tb tries to use <localized-trash-name> as "trash in Tb" according to mail.server.server#.trash_folder_name(this is wrong if actual Mbox nae is Trash at server). So, Mbox named <localized-trash-name> is created at server, and is used as "trash in Tb" according to mail.server.server#.trash_folder_name(this is wrong if actual Mbox nae is Trash at server). This Mbox is; actual Mbox name passed from servr = <localized-name-of-Trash in modified utf-7 which is passed via IMAP> actual msf file name = <localized-name-of-Trash in modified utf-7>.msf actual offline-store file name = <localized-name-of-Trash in modified utf-7> mail.server.server#.trash_folder_name = <"decoded localized-name-of-Trash in modified utf-7" in utf-8> Folder name at Folder Pane, Folder LIST UI = <decoded "localized-name-of-Trash in modified utf-7" in Unicode> If this is Mbox at server which user actully want to use as "trash in Tb", needless to say, mail.server.server#.trash_folder_name = <"decoded localized-name-of-Trash in modified utf-7" in utf-8> is correct. Confusion due to Bug 480393 was imported to nsImapIncomingServer.cpp by bug 1156669? Or, numFolders==0 case can occur after fix of bug 1156669 if Gmail IMAP and [Gmail]/Trash is hidden, but it's not cared?
(In reply to WADA from comment #51) > Quick summary of problem reports in this bug. > > > Comment # Comment poster IMAP server [Gmail]/Trash mail.server.server#.trash_folder_name > > > > Comment #0 Kees Middelburg ??? ??? ??? > > perhaps Gmail IMAP perhaps Unsubscribed perhaps "Trash" (no quote) > > > > Comment #9 Benjamin surely Gmail IMAP Hidden by Gmail "OLD MESSAGES" (no quote) > > > > Comment 10 Reporter surely Gmail IMAP Hidden by Gmail, "Storage" (no quote) or Unsubscribed it sounds for me Trash is used > > > > Comment 11 IPC surely Gmail IMAP ??? ??? > > To bug opener and all problem reportes(except already clearly stated > Benjamin's case) : > Please fill table by actual data of your case. See the corrected data in the table.
Flags: needinfo?(reporter)
When "Trash"([Gmail]/Trash is hidden by Gmail, following was observed in Tb 38. mail.server.server#.trash_folder_name = Trash (top level Trash, Gmail Laabel = [Imap]/Trash at Web Mail) Inbox is opened, so server.isGMailServer==true is normally returned. Collapse and Expand Gmail IMAP account "trash can icon" is shown for Trash => "trash can icon" is cleared at Trash "trash can icon" is shown for Trash again => "trash can icon" is cleared at Trash again => No folder has "trash can icon". When a folder has Trash attribute, if isGMailServer==true, if this folder doesn't have kImapXListTrash([Gmail]/Trash only has it), Trash attribute is cleared. So, If Gmail IMAP, Trash attribute of all folders other than [Gmail]/Trash is clered by DiscoveryDone. If so, in Tb 31, after DiscoveryDone, when [Gmail]Trash doesn't exist, someone stored Trash attribute to folder of mail.server.server#.trash_folder_name, because it had "trash can icon" in Tb 31. Folder Rediscovery is called twice in Tb 38? Just aafter restrt, Trash has "trash can icon" becaause set in mail.server.server#.trash_folder_name. => DicoveryDone clears Trash attribute of all folders because [Gmail]/Trash doesn't exist. => After it, someone set "trash ca icon" of Trash, if [Gmail]/Trash doesn't exist or no folder has Trash attribute. => In Tb 38, Folder Rediscovery is called again, so "trash can icon" of Trash is cleared by DiscoveryDone. => No one sets "trash can icon" of Trash. I couldn't find definition of GetIsGmailServer() / SetIsGmailServer() in MXR. incomingServer.isGMailServer=true is set when checked using JavaScript code, so isGMailServer=true is stored in C++ server object. GetIsGmailServer() returns false when called by DiscoveryDone in Tb 38?
Problem in current logic. Following code for "one trash only when loop is started" case is executed when non Gmail IMAP case only. > 1572 if (numFolders == 1) > 1573 { > 1574 // We got here because the preferred trash folder does not > 1575 // exist, but a folder got discovered to be the trash folder. > - SetUnicharValue(PREF_TRASH_FOLDER_NAME, folderName); > 1576 + SetUnicharValue(PREF_TRASH_FOLDER_NAME, nameUnicode); > 1577 continue; > 1578 } One of next may be needed. - Same of similar logic for numFolders==1 when Gmail IMAP. - "numFolders==1 in current code" is "only one trash can icon before start of clearing". so, insert "checking whether this is last trash caan icon folder or not" step, nd if "last trash caan icon folder", skip clearing Trash attribute. - After loop for clearing Trash attribute, do action for "numFolders==1 after clearing". If no trash can icon folder, use mail.server.server#.trash_folder_name.
FYI. By searching MXR for nsMsgFolderFlags::Trash, I found interesting code. > http://mxr.mozilla.org/comm-central/source/mailnews/base/util/nsMsgDBFolder.cpp#4358 > 4358 NS_IMETHODIMP nsMsgDBFolder::OnFlagChange(uint32_t flag) > 4366 #ifdef DEBUG_bienvenu1 > 4367 nsString name; > 4368 rv = GetName(name); > 4369 NS_ASSERTION(Compare(name, kLocalizedTrashName) || (mFlags & nsMsgFolderFlags::Trash), "lost trash flag"); > 4370 #endif This indicates that bienvenu sufferred from Trash flag loss in the past :-)
Trash flag clear logic in esr 31 was as follows. > http://mxr.mozilla.org/comm-esr31/source/mailnews/imap/src/nsImapIncomingServer.cpp#1425 > 1425 NS_IMETHODIMP nsImapIncomingServer::DiscoveryDone() > 1508 if (NS_SUCCEEDED(GetTrashFolderName(trashName))) > 1509 { > 1510 for (uint32_t i = 0; i < numFolders; i++) > 1511 { > 1512 nsCOMPtr<nsIMsgFolder> trashFolder(do_QueryElementAt(trashFolders, i)); > 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 } > 1536 } > 1537 } "if (isGMailServer)" block was altered between esr 31 and before check-in of Bug 1156669 which changed "if (isGMailServer){} else" block only. In esr 31, Trash attribute of any folder other than [Gmail]/Trash is cleared by DiscoveryDone() too, regsardless of "[Gmail]/Trash exists or not". So, logic for "store Trash attribute to a folder after DiscoveryDone() if [Gmail]/Trash doesn't exist" was perhaps lost between esr 31 and check-in of Bug 1156669. Check of both of following is needed. (a) change of "if (isGMailServer)" block in DicoveryDone() (b) logic for "store Trash attribute to a folder after DiscoveryDone() if [Gmail]/Trash doesn't exist" Revisions of nsImapIncomingServer.cpp. > http://hg.mozilla.org/comm-central/log/3ddf3a3eaf07/mailnews/imap/src/nsImapIncomingServer.cpp "continue in if (isGMailServer) block" is introduced by change of Bug 558659. Confusion between XLIST and LIST SPECIAL-USE was generated? nsMsgFolderFlags::Trash in comm-central. > http://mxr.mozilla.org/comm-central/search?string=nsMsgFolderFlags%3A%3ATrash nsMsgFolderFlags::Trash in esr 31. > http://mxr.mozilla.org/comm-esr31/search?string=nsMsgFolderFlags%3A%3ATrash&find=&findi=&filter=^[^\0]*%24&hitlimit=&tree=comm-esr31
Whiteboard: [problem after fix of Bug 1156669?][regression in Tb 38 over Tb 31] → [regression in Tb 38 over Tb 31]
FYI. Revisions of nsImapIncomingServer.cpp. > http://hg.mozilla.org/comm-central/log/3ddf3a3eaf07/mailnews/imap/src/nsImapIncomingServer.cpp Diff for change of nsImapIncomingServer.cpp by Bug 558659 > http://hg.mozilla.org/comm-central/rev/83b4178ffd06 Following logic was added by patch of Bug 558659, but it was added to non-Gmail-IMAP block only... if (numFolders == 1) { // We got here because the preferred trash folder does not // exist, but a folder got discovered to be the trash folder. SetUnicharValue(PREF_TRASH_FOLDER_NAME, folderName); continue; } "Gmail IMAP" && "[Gmail]/Trash is hedden" case was not cared?
neil@parkwaycc.co.uk, there is no need to care "one trash can icon folder" case or "no trash can icon folder" case in Gmail IMAP? If [Gail]/Trash is hidden or unsubscribed by user, such condition occurs...
Flags: needinfo?(neil)
Note: "if (numFolders > 1)" for entire loop for both Gmail IMAP and ordinal IMAP was removed by patch for Bug 558659...
Blocks: RFC6154
Severity: normal → major
Summary: 38.0.1, when I delete a message it is removed immediately instead of moved to the IMAP trash folder, because folder of Gmail IMAP which had Trash attribute folder has lost it's specialness which was set by mail.server.server#.trash_folder_name or by addon → 38.0.1, If [Gmail]/Trash is hidden at Gmail or unsubscribed by user, Trash flag of all folders is cleared, so no folder has "trash can icon", then "delete mail with move to trash model" silently skips "copy to trash" step and simply storess \Deleted flag
(In reply to WADA from comment #60) > neil@parkwaycc.co.uk, there is no need to care "one trash can icon folder" > case or "no trash can icon folder" case in Gmail IMAP? > If [Gail]/Trash is hidden or unsubscribed by user, such condition occurs... Originally only GMail provided an XList Trash folder. Furthermore, the code wanted to force GMail's Trash as the one true Trash folder. Unfortunately old profiles would have had an autocreated Trash folder, so when XList Trash support was added, that code block checked for an old profile by finding an autocreated Trash folder, and removed the flag. Now that several servers provide an XList Trash folder support was added to them in bug 558659. However unlike GMail the XList Trash folder was only used if no preferred Trash folder had been created yet. As such the check was moved as this then handled the new account case to prefer the server's XList Trash folder. Unfortunately as you point out this now fails to take into account Trash-less GMail accounts and the numFolders check should apply whether or not the server is a GMail server. The logic would then apply as follows: 1. If a GMail Trash folder is found, then this is the correct Trash folder 2. If a non-GMail preferred Trash folder is found, then this is the correct Trash folder 3. If only one Trash folder is found, then this is the preferred Trash folder 4. No other folder may be the Trash folder. The Trash folder priority would then be as follows: 1. GMail Trash 2. Preferred Trash 3. Other XList Trash 4. Default Trash
Flags: needinfo?(neil)
(In reply to neil@parkwaycc.co.uk from comment #62) Thanks for quick answer.
(In reply to neil@parkwaycc.co.uk from comment #62) Please care "ZERO trash case in Gmail IMAP". ABC exists on server, and user sets mail.server.server#.trash_folder_name = ABC. user shows [Gmail]/Trash, so [Gmail]/Trash is used as trash. Because ABC is not used, user deletes ABC at server, and Tb detects it. User hides [Gmail]/Trash at Gmail Web Interface. Folder Re-discovery by Collaps/Expand of Gmail IMAP account. In this case, "ZERO trash" may occur even if this bug will be fixed by correct processing of "One trash" case. I believe that mail.server.server#.trash_folder_name = ABC is normally used at least by next Collapse/Expand of account, even if such phenomenon may happen. However, "ZERO trash can icon folder" is mystery for user. It's better avoided.
(In reply to neil@parkwaycc.co.uk from comment #62) Please care "ZERO trash case in Gmail IMAP". ABC exists on server, and user sets mail.server.server#.trash_folder_name = ABC. user shows [Gmail]/Trash, so [Gmail]/Trash is used as trash. Because ABC is not used, user deletes ABC at server, and Tb detects it. User hides [Gmail]/Trash at Gmail Web Interface. Folder Re-discovery by Collaps/Expand of Gmail IMAP account. In this case, "ZERO trash" may occur even if this bug will be fixed by correct processing of "One trash" case. I believe that mail.server.server#.trash_folder_name = ABC is normally used at least by next Collapse/Expand of account, even if such phenomenon may happen. However, "ZERO trash can icon folder" is mystery for user. It's better avoided.
To neil@parkwaycc.co.uk: If you will propose patch, please open separate/crisp bug and propose patch in the new bug. Because this bug is filled by comments for problem analysis(who can easily imagine '[Gmail]/Trash is hidden'?), this bug's state is already not-so-easy-to-read-thru, not-so-easy-to-understand, not-so-easy-to-follow state. And, I believe that "bug for problem analysis by bug opener/comment posters/QA peoples" and "bug for fixing bug/proposing patch by developer" is better separated.
User Story: (updated)
Blocks: 1156669
status-thunderbird41: --- → wontfix
status-thunderbird42: --- → affected
status-thunderbird43: --- → affected
status-thunderbird44: --- → affected
status-thunderbird_esr38: --- → affected
Whiteboard: [regression in Tb 38 over Tb 31] → [regression:Tb38]
I'm trying to clear out some old NI requests. Looking at the bigger picture, the issue in this bug is not as severe as the issue in bug 1156669, so it does not make sense to back out that to prevent this. Someone needs to propose code to fix the issues in this bug, that walks the narrow path between the problems of bug 1156669, and the problems here. I can't really say more without spending a day or two diving into the code myself.
Flags: needinfo?(rkent)
Probably I have the same issue: when I delete a mail in (IMAP) Gmail inbox, it's totally removed instead of being moved to my trash folder. The folder I use as trash isn't the default one, but a folder created by me and selected like this in TB. It's so frustrating.. any fix?
(In reply to elmhaxx from comment #68) > It's so frustrating.. any fix? This bug is for following phenomenon. 1. User wants to use top level Trash as "trash in Tb with move to trash model" instead of [Gmail]/Trash. > => Hide [Gmail]/Trash in Gmail IMAP via Gmail's setting. > This is known as a workaround of Bug 533140. 2. This workaround of Bug 533140 worked, but this doesn't work after a Thunderbird release. > "trash can icon" of all folders under the Gmail account in Thunderbird is cleared. > => "Delete mail with move to trash model" === "move mail to folder which has Trash attribute(has trash can icon)" > So, "delete a mail in Tb" silently stores \Deleted flag in the mail. > => Because "auto-expunge=On" is default in Gmail's setting, the "mail flagged as \Deleted in Inbox" disappers from Inbox. > => The mail is still held in [Gmail]/All Mail, because the "deleted mail" is not copied/moved to [Gmail]/Trash. > Merely "Gmail Label named Inbox" was removed from the mail. "No folder has trash can icon" state in Thunderbird === state when IMAP delete model="Just mark it as deleted" is set by you. So, above state is absolutely same as "Just mark it as deleted is set by you at Server Settings of Thunderbird", except that you can not copy/move mail to [Gmail]/Trash because you hided [Gmail]/Trash at Gmail's IMAP setting. If you want to add Gmail Label named [Imap]/Trash to the mail at Gmail's Web interface, move the mail to "top level folder named Trash in Thunderbird", instead of using DELETE key.
Sorry but I haven't understood so good what you suggested. To be clear: I created a folder named "Deleted" in my Gmail and I used as folder where to move deleted mails in TB (setting "Move it to this folder: Deleted on Gmail"). From a certain TB version (1-2 years ago, I can't remember) it has started to not work. The workaround I use after *every* TB launch is to set "Just mark ti as deleted" and then set "Move it to this folder: Deleted on Gmail". In this way the Deleted folder icon in Gmail tree becomes like a trash, and everything works good (that is when I delete a mail in inbox it's moved into Deleted folder as expected). Now: is there a TB fix to avoid I have to use this annoying workaround? Thank you for your support.
(In reply to elmhaxx from comment #70) > To be clear: I created a folder named "Deleted" in my Gmail > and I used as folder where to move deleted mails in TB > (setting "Move it to this folder:Deleted on Gmail"). > > From a certain TB version (1-2 years ago, I can't remember) it has started to not work. As clearly written in Version: field/ Whiteboard: field of this bug, phenomenon of this bug started to occur from Thunderbird 38. > The workaround I use after *every* TB launch is to set "Just mark ti as deleted" > and then set "Move it to this folder: Deleted on Gmail". > In this way the Deleted folder icon in Gmail tree becomes like a trash, and everything works good > (that is when I delete a mail in inbox it's moved into Deleted folder as expected). Your workaround is proper/valid. (1) When "IMAP delete model" is changed from "Just mark it as deleted" to "Move to trash with trash=Deleted", Thunderbitd stores "Trash special folder state" into Deleted folder, and adds trash can icon to the Deleted folder. (2) Because folder of "Trash special folder state" exists, Thunderbird moves mail to the "Deleted" folder when "Move to trash" is set at Server settings. However, it works merely "a while". (3) When folder rediscovery is done by Thunderbird on Gmail IMAP account(isGmail==true), Thunderbbird clears "Trash special folder state" of all folders under the Gmail IMAP account. The "folder rediscovery" occurs at least when account at folder pane is collapsed and expanded. (3-1) And, Thunderbird tries to store "Trash special folder state" to [Gmail]/Trash because of Gmail IMAP. (4) However, (4-1) you hided [Gmail]/Trash via Gmail Web setting, or you unsubscribed [Gmail]/Trash. Therefore, Thunderbird can't store "Trash special folder state" in [Gmail]/Trash. => (4-2) state of "no folder has trash can icon" happens. => upon delete of mail with "Move to trash with trash=Deleted", (4-3) "copy to trash" step can not be executed because there is no folder of "trash can icon", (4-4) and "delete from Inbox" step of "Delete with move to trash model==Copy+Delete" is silently executed. (5) Because you are aware of "no trash can icon" state, you do (1). => Infinite loop of (1)/(2) -> (3) -> (4) -> (1)/(2) -> (3) -> (4) -> (1) -> ... (2)/(4-3)/(4-4) is logic used for long time. (perhaps inherited from NetScape Messenger) (3-1) is for same behavior in delete mail between Gmail Web Interface and Thunderbird. This is intentionally done in order to avoid general user's confusion. This is done also in order to avoid useless bug open at B.M.O by general users who is majority of Thunderbird users. As you know well, (4-1) is a workaround of Bug 533140. Problem of this bug is (4-2) when (4-1) was intentionslly done by user in order to bypass Bug 533140. > Now: is there a TB fix to avoid I have to use this annoying workaround? You can do your workaround easily by utilizing Custom Buttons addon. (a) Add your Toolbar button using Custom Buttons. By Button script, store "Trash special folder state" into your "Deleted" folder. This can be done by very simple script. You can do your workaround by merely clicking a button. A button created using Custom Buttons is a "pretty small your own addon" created merely by writing a script code. Another possible way: (b) By button script, watch "Trash special folder state" of your "Deleted" folder, and store "Trash special folder state" into your "Deleted" folder if Tb cleared it. => Infinite fight between you and Thunderbird :-) I'm comment poster of comment #22. I changed name of my addon for Thunderbird testing to WinBackMyTrash when I knew Bug 533140. This means : Win Back My Trash from Gmail IMAP and Thunderbird developers and general Tb users! :-) I tried to write code for (b) when I changed my addon name to WinBackMyTrash. But I merely wrote code for (a) only, because far important functions than (b) was/is needed for me.
Sorry but I don't understand totally what you wrote, like a "programmer".. :) Anyway to summarize: - the bug I reported is known (from Thunderbird 38) - my workaround is good Now let me ask: - workarounds you suggested are simpler than mine? have I to write code?! (script..) - will this bug be fix?
Kees writes, "I cannot really help. Shortly after I posted the problem, I started to use a trash in my local folders (to get round the problem). And 1.5 year later, I cannot remember more than I mentioned initially. "
Flags: needinfo?(kees.middelburg)
Whiteboard: [regression:Tb38] → [regression:Tb38][key comnment 67]
> started to use a trash in my local folders (to get round the problem). And So is this the workaround? And how can I do it with my Gmail IMAP account? Have I change the trash folder from my "Deleted" one to another as local?
(In reply to elmhaxx from comment #76) > > started to use a trash in my local folders (to get round the problem). And > So is this the workaround? > And how can I do it with my Gmail IMAP account? Have I change the trash > folder from my "Deleted" one to another as local? There is currently(and since initial of imap support by Tb) no way to use local mail folder(folder of Local Folders, POP3) as "trash folder of an imap acccount in Tb", as far as I know and as far as I understand. And, there is no way for "Using Trash of Local Folders as trash folder of ordinal POP3 account". Only way I know to use "Trash of Local Folders" as "trash folder of an account in Tb" : 1. Change current imap account in Tb to type=pop3 account by changing prefs.js manually. 2. Use Global Inbox for the faked pop3 account : Use folders of Local Folders for the faked/hidden pop3 account. => Relevant account in Tb can use "Trash of Local Folders" as "trash folder of the relevant account". I can't understand purpose and reason why such comment was posted to this bug. By addon, it may be possible, but I don't know. It may be following: If you are so eager to hide [Gmail]/Trash and "hiding [Gmail]/Trash" is one of most important/valuable thing in your life, manually move mail to Trash of Local Folders. That's all. Mail is copied to Trash of Local Folders, and is never removed from [Gmail]/All Mails, so no mail won't be lost in Gmail account. It's merely "loss of Gmail Label=Inbox from the mail by move mail".
Sorry, typo. Mail is copied to Trash of Local Folders, and is never removed from [Gmail]/All Mail, so any mail won't be lost in Gmail account. It's merely "Gmail Label=Inbox is removed from the mail by the move mail operation".
(In reply to elmhaxx from comment #72) > Sorry but I don't understand totally what you wrote, like a "programmer".. First of all, please note that here is B.M.O. for developers to resolve actual bug(flaw in code in Tb), and here is never support forum nor Customer Help Center. From perspective of software design/implementation, this bug is as follows. (1) Design == Force [Gmail]/Trash as "trash in Gmail IMAP account in Tb", in order to avoide excess bug open at B.M.O due to confusions caused by mismatch between "trash in Tb" and "trash in Gmail Web mail". (2) Someone found hole in implementation of (1) in Bug 533140. (3) Some peoples utilized the hole in implementation of (1), as you did. (4) The "hole in implementation of (1)" is not intentional, and the "hole in implementation of (1)" won't produce critical problem, so no one tried to close the hole. (5) After it, the hole was closed, but phenomenon when the "hole in implementation of (1)" was utilized by some peoples were morphed to phenomenon of this bug. We already analyzed why (5) occurs. However, this bug is for phenomenon when someone utilized "hole in implementation of (1)". Developers and QA peoples at B.M.O are volunteers, and they never works foy you only. Developers are busy to resolve important bugs. Even if any user currently can open any bug at B.M.O and any user currently can add any comment to bug in B.M.O, here is B.M.O for developers and is never support forum nor Customer Jelp Center.

I think since most users just use the default gmail setup that there is no problem with trash folder. At least I haven't seen one.

Severity: major → normal

But how long do you think you have to work to fix this bad issue?

(In reply to elmhaxx from comment #81)

But how long do you think you have to work to fix this bad issue?

Don't understand your comment.

Not sure from skimming the verbose stuff above what the problem is. If you are interested in this bug, please restate exactly what the problem is, if you don't mind. That would really help. Thanks.

Is this clear?

... I created a folder named "Deleted" in my Gmail and I used as
folder where to move deleted mails in TB (setting "Move it to this folder:
Deleted on Gmail").

From a certain TB version (1-2 years ago, I can't remember) it has started
to not work. The workaround I use after every TB launch is to set "Just
mark ti as deleted" and then set "Move it to this folder: Deleted on Gmail".
In this way the Deleted folder icon in Gmail tree becomes like a trash, and
everything works good (that is when I delete a mail in inbox it's moved into
Deleted folder as expected).

Now: is there a TB fix to avoid I have to use this annoying workaround?

(In reply to elmhaxx from comment #83)

Yes, I see that you can set a "non standard" trash name and it works but it reverts back to the standard [Gmail]/Trash folder on tb restart. I think WADA's point is that this is intentional. Also I think 99.9% of users are perfectly happy with the default [Gmail]/Trash being the trash destination. However, you prefer the destination to be [Gmail]/Deleted it seems. Curious why the name "Deleted" instead of "Trash" is important for some users? (Edit: reason sited by many users is because gmail trash deleted in 30 days. Maybe some people just prefer a different name like "RoundFile".)

Gmail's imap (they call it GIMAP) is a very liberal interpretation of the IMAP RFCs and they do things that other more "standard" imap server, like dovecot, don't do like assuming a specific name for Trash and auto-moving (labeling) deleted items to it. (Edit: messages marked deleted are not moved to, actually labeled, Trash by gmail. But they are auto-expunged by default which can be set at gmail site. Tb has to tell gmail to copy mail to Trash folder before setting deleted flag.) So at this point, I'm inclined to vote to close this bug as WONTFIX. (Edit: Well maybe not. Pending further discussion after comment 97.)

Note also that the problem described in comment 83 is considerably different than the original reporter's comment 0 description, which seems to be fixed. (Edit: After looking closer, I think reporter at comment 0 had selected an alternate trash folder name. In that case, it is really the same as comment 83 and bug 533140.)

Are you saying that if I rename the folder "Deleted" into "Trash" under Gmail, everything in Gmail and TB work good? is this the problem, I created a folder for my emails different than "trash"? how can I know it was the only name TB lets you use..?

(In reply to elmhaxx from comment #85)

Are you saying that if I rename the folder "Deleted" into "Trash" under Gmail, everything in Gmail and TB work good? is this the problem, I created a folder for my emails different than "trash"? how can I know it was the only name TB lets you use..?

I can't swear that will fix it but probably will. Works for me. The reason is because when you set up a gmail account, gmail creates a [Gmail]/Trash folder (or possibly gmail provides a localized name for non-EN locations, not sure) and when tb connects and "lists" the folders, gmail tells tb that [Gmail]/Trash is the designated trash folder so it has the expected icon (and for other reasons). So check on gmail site and make sure you still have the Trash folder there and it is set so it is visible via imap. You can also remove the "Deleted" folder there, I think. Then in tb make sure [Gmail]/Trash is subscribed and visible (a restart may be needed) and set tb so deletes go to [Gmail]/Trash and no longer to "Deleted". If you didn't remove the Deleted folder at gmail site you can delete it via TB now if you want (or rename it to something else or just keep it, doesn't matter).

Note: Or maybe, as you say, you can just rename Deleted to [Gmail]/Trash in tb. Not sure, but I would recommend the procedure I described.

Also, elmhaxx, make sure that the Trash folder is under the gray [Gmail] folder and not outside of it at the same level as INBOX. By default, gmail puts trash under [Gmail] so shouldn't be a problem.

Another consideration is some help sites recommend that you just use "Just mark it as deleted" rather than move to [Gmail]/Trash for the delete method. The rationale can be found here: http://kb.mozillazine.org/Using_Gmail_with_Thunderbird_and_Mozilla_Suite , specifically:

Gmail recommends that you do not use [Gmail]/Trash as your Trash folder since Gmail only keeps a single copy of a message with multiple labels. If you delete a message that way you're also telling it to delete the same message from any other folder (label) that has that message. [12][13] Gmail recommends not making Thunderbird move deleted mail into any folder and instead choose "Just mark it as deleted" from "When I delete a message" in Account Settings -> Server Settings.

This means you still need to have the [Gmail]/Trash folder but the way gmail imap (GIMAP) works is that anything you delete will automatically be put into (actually labeled) with [Gmail]/Trash so you don't need to tell tb to also move the deleted message to [Gmail]/Trash. (I haven't tested this recently but I think it is correct. I use move to trash and don't see problems, but I'm not a gmail on tb power user.)

Edit: I just tested with "just mark as deleted" and it doesn't work the way I expect. So I recommend ignoring the suggestion above. Sorry.

Ok, dependent bug 533140 is basically the same complaint. It brings up a good point that is not mentioned in this bug, or maybe it is but I missed it. A problem with being required (forced actually) to use [Gmail]/Trash is that anything put there is automatically deleted in 30 days. Lots of imap servers do a similar thing for their standard Trash folder but you can always point the tb's trash destination to a another folder that is not subject to auto-deletion.

A suggestion by WADA (bug 533140 comment 40) was to make a code change in the function DiscoveryDone() that, enabled by a new hidden preference, allows tb to treat gmail accounts like non-gmail accounts and respect and keep the user's setting for the trash destination folder. Currently for gmail, when tb starts up and folders are discovered, the gmail LIST response tells tb that [Gmail]/Trash is the trash folder so this overrides the user's selection for trash destination.

I made the suggested change but made it unconditional in my development build and it seems to work OK. I didn't add the hidden pref to enable it. Now I can set any folder of the gmail account to be the trash destination (just like non-gmail servers) and it now remains set on tb restart.

A problem pointed out by WADA is that when the Language setting is changed at the gmail site, this might cause problems. I don't see a problem. I tested it with French, EN-UK and EN-US and the name shown for the trash folder changed from Corbeille to Bin to Trash respectively. I did have to re-set the trash destination to the new name but it didn't seem to be a problem. Also, with any language active, I was still able to set the trash destination to any subscribed folder and it stuck after restart. But maybe I am missing something about this.

With the proposed changed, I also tested a new gmail account creation and the default [Gmail]/[Corbeille || Bin || Trash] folder is still auto-configured as the trash destination.

The attached diff just shows the one-line change I made to test the concept.

Assignee: nobody → gds
Attachment #9080522 - Attachment description: t.diff → Cause gmail account to respect the user's selection for trash folder.

Gene, let me understand.. have you fixed the issue? haven't I to try to rename my folder Deleted into Trash as you suggested before?

The reason why I created a folder named "Deleted" was probably because of the already used name "Trash" by Gmail as auto-delete after 30days.. if I remember good, but I could be wrong..

(In reply to elmhaxx from comment #89)

Gene, let me understand.. have you fixed the issue? haven't I to try to rename my folder Deleted into Trash as you suggested before?

The reason why I created a folder named "Deleted" was probably because of the already used name "Trash" by Gmail as auto-delete after 30days.. if I remember good, but I could be wrong..

The "fix" I posted is just a proposal and hoping it might elicit comments from others CC's on this bug without requesting a "need info". But even if everyone says "yes, sound great, do it" it would be months before a the fix is in a beta and possibly even a release. So, if you can live with the 30 day trash life that gmail has, you should go ahead and still do what I recommend: go back to making your "Deleted" folder "[Gmail]/Trash".

Note: There are other workarounds mentioned in bug 533140, like mapping delete key so it archives (moves to All Mail) but none sound too appealing to me.

My emails can't be deleted after 30 days, I need to keep each one of them.

So I deduce I can't rename "Deleted" into "Trash" if "Trash" has the 30-days auto-purge: right?

(that's why in the beginning I had to create a brand new folder called "Deleted")

(In reply to elmhaxx from comment #91)

My emails can't be deleted after 30 days, I need to keep each one of them.

So I deduce I can't rename "Deleted" into "Trash" if "Trash" has the 30-days auto-purge: right?

(that's why in the beginning I had to create a brand new folder called "Deleted")

That's right. According to gmail their standard "Trash" folder will have its content removed in 30 days. I don't see an option on gmail site to disable this time limit.

There was a lot of interest in this issue 10 years ago when this bug was first entered (Edit: actually bug 533140). Other than you, I'm not sure if there is any interest now. A fairly easy fix was identified in bug 533140 comment 40 that I have tested with Attachment #9080522 [details] [diff] (minus an enabling pref).

Therefore the question to the tb project management is whether this needs to be fixed or not.

Flags: needinfo?(vseerror)
Flags: needinfo?(mkmelin+mozilla)
Flags: needinfo?(jorgk)

Any valid bug needs to be fixed. Particularly out Gmail support needs to be improved.

Flags: needinfo?(jorgk)

A fairly easy fix was identified in bug 533140 comment 40 that I have tested with Attachment #9080522 [details] [diff] (minus an enabling pref).

Is it a software fix or workaround for users?

Therefore the question to the tb project management is whether this needs to be fixed or not.

Absolutely to be fixed. I'm not the only one, many other friends and users asked me about the solution! In any case, please fix it now or never, after 10 years.. Sure, I can test the bug fix if you need.

Thanks.

Yeah - gmail doesn't get much love :)

"Trash is hidden at Gmail or unsubscribed by user" is surely an edge case? But IF it's trivial to fix with no downside risk then sure, go for it. If not easy to fix, then should it be given priority above other (gmail) issues is another question. And if it matters whether this is something commonly seen - is better answered by those closer to support, and some who have a better eye for gmail issues (I've cc some).

(Personally, hasn't bothered me, but I don't hold myself up as a typical example - I'm just one.)

Flags: needinfo?(vseerror)

Perhaps a silly question, but why are users doing things like "Trash : 'Shown in IMAP' = UNTICKED in gmail settings" in the first place?

(In reply to Wayne Mery (:wsmwk) from comment #96)

Perhaps a silly question, but why are users doing things like "Trash : 'Shown in IMAP' = UNTICKED in gmail settings" in the first place?

The main concerning with using and showing in imap gmail's trash folder is that the mail put there is deleted after 30 days. I think it is also not in All Mail too after that time. If you could tell tb to put deleted mail in another folder it would stay forever, but you can't permanently do that now. Of course this is a bit confusing since gmail uses labels and doesn't really put things in "folders" that tb shows, but gmail's imap simulates the folders.

The user unsubscribing or disabling for imap the Trash folder at gmail site is not really a problem. The problem is that the user (e.g., elmhaxx) wants to assigned an alternate folder for trash to nullify the 30 day limit. He can set it one time and it works while tb is running. When you restart tb, the setting appears to still be set, but your deleted emails don't go to your designated trash folder, they are just gone. So not really an edge case to want to have deleted emails stick around and not be removed automatically by the email provider.

(In reply to Wayne Mery (:wsmwk) from comment #95)

"Trash is hidden at Gmail or unsubscribed by user" is surely an edge case? But IF it's trivial to fix with no downside risk then sure, go for it. If not easy to fix, then should it be given priority above other (gmail) issues is another question. And if it matters whether this is something commonly seen - is better answered by those closer to support, and some who have a better eye for gmail issues (I've cc some).

I don't think it is really just an edge case. The fix I proposed in the attached diff seems very simple and seems to work for me even when I set gmail site to various languages. However, the problem sited around bug 533140 comment 40 mentions other problems when the user's tb is localized somewhere other than US, which I'm not. I don't completely understand the issues regarding this so that's why I asked for more comments rather than just submitting a formal patch.

Note also that bug 533140 more accurately describes the problem. Bug 533140 comment 40 also sites a possible javascript problem that I don't understand. I don't see it stated but I assume the reporter of this bug, Kees in comment 0, was using an alternate Trash folder too.

I guess if this is as simple as it seems it would have been fixed 10 years ago when Bug 533140 was submitted.

Gmails 30 day deletion is still confusing to our users. They regularly report issues, not only with gmail, where Thunderbird is set to delete nothing and the trash file keeps emptying itself. I think perhaps we need to rethink deleted as users appear to think deleted is "completed" and the trash is a large completed items folder.

However if a simple fix is available for gmail. Go for it is my feeling.

(In reply to Matt from comment #98)

Gmails 30 day deletion is still confusing to our users. They regularly report issues, not only with gmail, where Thunderbird is set to delete nothing and the trash file keeps emptying itself. I think perhaps we need to rethink deleted as users appear to think deleted is "completed" and the trash is a large completed items folder.

With my proposed fix, another folder name like "RoundFile" can be designated as trash destination. Other than the possible localization issues, one problem with it is that messages deleted to RoundFile will, of course, not be in the gmail's Trash. Therefore when messages are deleted from RoundFile or RoundFile is emptied, the messages will still be in [Gmail]/All Mail and not really gone. Also, if the same message exists in multiple folders, when deleted from one of the folder, the message will remain in all the other folders; however, this may be good and what most users expect. To permanently and completely delete the message, including from All Mail, all copies in multiple folders would need to be moved to gmail's Trash using tb (assuming [Gmail]/Trash is visible via imap and subscribed in tb), or at gmail site, delete the message to Trash in a single folder which will put all copies effectively in Trash. Then delete or empty trash at gmail site; this can't be done in tb (* see below) since [Gmail]/Trash is now not the designated trash folder. So these extra step are needed to completely erase a message from gmail.

Of course, even with my proposed fix, when a gmail account is created in tb, tb will set [Gmail]/Trash as the trash destination initially. I suspect most users are OK with that and will just leave it as is. However, even with this default setting there may be issues other than just the 30 day trash limit. One is that if you have the same message copied to multiple folders and you delete it in any one of the folders, all copies will effectively be moved to Trash. Then when it is deleted from Trash or when Trash is emptied, since it is truly in gmail's Trash, it will completely removed from gmail, including All Mail.

The above is based on doing detailed tests with tb and gmail since I wasn't completely sure how it works. The tb/gmail/imap documentation I could find was not always real clear. The discussion also assumes that the imap setting at the gmail site are default.

(*) A possible way to to still empty [Gmail]/Trash in tb with RoundFile as the designated trash folder is to temporarily set the delete method to "Delete immediately" and then delete the messages copied to [Gmail]/Trash. This should mark them all with imap \deleted and expunge the deleted messages in [Gmail]/Trash so the the messages are completely deleted from gmail, even from All Mail. (I haven't actually tested this.)
Edit: Now I have tested it. A problem is that when the messages in Trash are marked \deleted by tb, and even though gmail site is configured with the default "When I mark a message in IMAP as deleted, auto-expunge on -- immediately update the server" this doesn't seem to apply for Trash. I had to also compact Trash in tb which expunges the Trash folder to remove the messages from Trash folder and from gmail completely. (I noticed also that when a message that exists in one or more folders is moved to Trash, it only exists in Trash and is also now not listed in All Mail.)

Attached patch 1175446-review-changes-v0.patch (deleted) — — Splinter Review

Here's a formal patch for review and feedback. All it does treat any user selected folder for any server, including gmail, the same. It has exactly the same effect as my previous attached diff attachment #9080522 [details] [diff] [review] (set obsolete). It allow the user to use any gmail account folder as the trash destination, not just [Gmail]/Trash.

I haven't yet been able to test this with the Trunk version since the build seems to be hanging and not progressing for long periods. All I see now while building is python2.7 in top. When actually building and before hanging I see rust and clang in top, but now just python2.7. On the screen I see this with nothing new for a long time:

:
17:42.88    Compiling hyper v0.12.19
17:53.29    Compiling warp v0.1.16
18:00.25    Compiling webdriver v0.39.0 (/home/gene/mozilla2/testing/webdriver)
18:42.84     Finished dev [optimized + debuginfo] target(s) in 16m 32s
ttER: configure pre-export export compile misc libs tools

compileis underlined so at compile step.
Edit1: Well, rebooted and build seems to be progressing now. We'll see how it goes...
Edit2: Build finished and patch seems to work.

Attachment #8624071 - Attachment is obsolete: true
Attachment #9080522 - Attachment is obsolete: true
Attachment #9081186 - Flags: review?(jorgk)
Comment on attachment 9081186 [details] [diff] [review] 1175446-review-changes-v0.patch This looks like a big patch, but in fact it only removes one block of code controlled by `if (isGMailServer) {` like the WIP in attachment #9080522 [details] [diff] [review] did. I'm neither a Gmail user nor friend, so I'll leave this to Magnus to decide and test. I see an open NI here anyway.
Attachment #9081186 - Flags: review?(mkmelin+mozilla)
Attachment #9081186 - Flags: review?(jorgk)
Attachment #9081186 - Flags: feedback+
Comment on attachment 9081186 [details] [diff] [review] 1175446-review-changes-v0.patch Review of attachment 9081186 [details] [diff] [review]: ----------------------------------------------------------------- Yeah looks ok.
Attachment #9081186 - Flags: review?(mkmelin+mozilla) → review+
Status: NEW → ASSIGNED
Flags: needinfo?(mkmelin+mozilla)

Thanks Magnus. I want to try to make "try" test build for user elmhaxx (comment 94).

Elmhaxx, it will be en-US localized so I think that's OK.

elmhaxx, Here's a link to a test "try" build with the patch to allow a user specified trash folder to remain in effect after a tb restart. I'm assuming that a 64-bit windows version is OK so here is the link to the installer:

https://queue.taskcluster.net/v1/task/SGFoyLjBTvGizBrc1LKA9A/runs/0/artifacts/public/build/install/sea/target.installer.exe

If this is not ok, you can also get a 32-bit version on this page:

https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&collapsedPushes=525525&selectedJob=259862704&revision=2015050efc07206a670a96245dee1dc0de2d9bef

Click on the green B next to "Windows 2012 opt" to select the 32-bit build. Then when info comes up at the bottom, click on "Job Details". Then scroll down until you find "target.installer.exe" which you can then download. (Note: Ignore the versions that mention debug. I built them by mistake. They will work but are probably larger and slower since they are not optimized. Also, you can access the 64-bit version installer through this page too.)

When you run this Thunderbird version it will indicate that it is "daily" I think, but my patch will be included even though it is not yet been pushed to daily. Let me how it works for you and feel free to share it with others that you mentioned that have this issue.

Edit: Alternatively, I have done this build with the patch applied to ESR60 release. It may be more "stable" than the daily linked above and may work better with any add-ons you may be using:
https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&collapsedPushes=525525&revision=70db47cf5670d79ba62a36b4b8b73b0d740c5d5e
I didn't include the "debug" versions this time and left out all the unit tests. Again, just click the "B" beside the desired version and down below under "Job Details" find the link for "target.installer.exe" and download it.

After a bit of delay, commenter/reporter elmhaxx did a test on the "try" version and it solves his problem. Here's what he wrote in a email to me:

I've just tried your TB version and it seems to be good!

I've found the folder (Gmail) "Deleted" already with the right icon 
after the TB launch; also deleting mails in (Gmail) inbox moved them 
into the folder "Deleted".

Alright: if you haven't other test, when could it be available as 
official version?

Thanks.

So, as I expected, the patch solves the problem.

Commenter elmhaxx has again requested status on this via email. So this informs him that I can't commit or land the patch and am waiting on action by Magnus or possibly Jorg.

Flags: needinfo?(mkmelin+mozilla)
Flags: needinfo?(jorgk)

If you need something checked in, just set the "checkin-needed" keyword. I'll land it now.

Flags: needinfo?(mkmelin+mozilla)
Flags: needinfo?(jorgk)
Comment on attachment 9081186 [details] [diff] [review] 1175446-review-changes-v0.patch I guess you want this in TB 68 ESR at some stage.
Attachment #9081186 - Flags: approval-comm-esr68?

Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/b1e49a0013b6
Allow Gmail account to work correctly with a custom Trash folder. r=mkmelin

Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED

Hmm, this has been sitting here inactive since Aug 15th. That's unfortunate, but if you don't request checkin, it might get forgotten. I follow most active bugs, but with 200+ bugmails per day, I can't follow every detail of everything.

Target Milestone: --- → Thunderbird 70.0

(In reply to Jorg K (GMT+2) from comment #108)

Comment on attachment 9081186 [details] [diff] [review]
1175446-review-changes-v0.patch

I guess you want this in TB 68 ESR at some stage.

Yes.

I didn't know I needed to "request check in". Always before the reviewer with check-in privilege (you) did the check-in as soon as giving it a +. This is the first time for me the reviewer was someone other than you (Magnus) so I assumed he would do the check-in just like you always did.

We usually let the patch author set checkin-needed, as he has the best over all picture for the bug he's fixing.

(In reply to Magnus Melin [:mkmelin] from comment #112)

We usually let the patch author set checkin-needed, as he has the best over all picture for the bug he's fixing.

Ok, I'll remember that.

Regressions: 1579304
Comment on attachment 9081186 [details] [diff] [review] 1175446-review-changes-v0.patch Together with bug 1579304 of course.
Attachment #9081186 - Flags: approval-comm-esr68? → approval-comm-esr68+

After installing 68.1.1, received this email from commenter elmhaxx:

On 9/26/19 2:37 AM, elmhaxx wrote:> It works! :)
> 
> So.. I have to thank you to have solved an issue none fixed in many years :O
> 
> Really, thanks a lot.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: