Closed Bug 1579304 Opened 5 years ago Closed 5 years ago

Deleting messages no longer working with Gmail IMAP

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, thunderbird71 fixed)

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

People

(Reporter: 52qtuqm9, Assigned: jorgk-bmo)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

1579304-gmail-fix.patch
4.21 KB, patch
gds
: review+
jorgk-bmo
: approval-comm-beta+
jorgk-bmo
: approval-comm-esr68+
Details | Diff | Splinter Review

I'm viewing my "All Mail" folder in Gmail. I delete a message in that folder. The message disappears. A couple seconds later, it reappears. This happens consistently.

I regressed this with mozregression and got this:

 6:48.28 INFO: No more inbound revisions, bisection finished.
 6:48.28 INFO: Last good revision: 89a77f62b2dd39aa9d1c4306e9997247404b6783
 6:48.28 INFO: First bad revision: 8e5b49be96e386fd28cea47291bf932f8ce4e8af
 6:48.28 INFO: Pushlog:
https://hg.mozilla.org/comm-central/pushloghtml?fromchange=89a77f62b2dd39aa9d1c4306e9997247404b6783&tochange=8e5b49be96e386fd28cea47291bf932f8ce4e8af

The patch landed for bug 1175446 is almost certainly the culprit.

Jonathan, so you're reporting this for TB 70 which is being released as beta today? That would be pretty bad :-(

Magnus and Gene, what do you say?

But hold on? "All Mail"? That's that funny Gmail construct. Do you have a custom trash folder that Gmail doesn't consider trash? So the message is moved from a folder to a trash folder not recognised by Gmail and thus shows up in "All Mail"?

Flags: needinfo?(mkmelin+mozilla)
Flags: needinfo?(gds)
Regressed by: 1175446
Version: Trunk → 70

I do not have a custom Trash folder, I use the standard Trash folder that gmail expects me to use.

I don't see this on trunk.

Flags: needinfo?(mkmelin+mozilla)

OK, this is interesting...

When I have this in prefs.js the problem does not occur:

user_pref("mail.server.server5.trash_folder_name", "[Gmail]/Trash");

When I don't have that in prefs.js, the problem occurs.

I went and looked at my prefs.js backups which I have since April 2019 and I never had that pref before, so perhaps it was recently added and the problem is that the code isn't backward compatible to before it existed?

That pref has always existed and it's set when you select the trash folder.

This looks like a bug that only affects good guys like you who always went with the default and never had the pref set.

Good information, I'll write something into the release notes for TB 70.

I was afraid there might be issues like this. So the release note will say to explicitly set the trash destination to [gmail]/Trash, I assume. I will check closer on this later if that's OK.

Flags: needinfo?(gds)

Disclaimer: I don't like Gmail, I don't use Gmail, and I know little about Gmail. That said, I have two Gmail accounts.

So I opened one of them and looked at my prefs. mail.server.server11.trash_folder_name was set to [Gmail]/Trash. So I reset it. I deleted a bunch of test e-mails from "All Mail" and they all went to the Trash and didn't bounce back. BTW, can someone explain to me what "All Mail" is? I thought it was a collection of all mail from all other folders, but it had some mail not seen in any other folder.

I restarted TB, and the pref came back. Most likely TB talks to the Gmail IMAP folder and asks about the folders and stores the pref for the trash folder. That happens here during discovery:
https://searchfox.org/comm-central/rev/90d756d83214006e9ddc9e6de13dc138bd478af3/mailnews/imap/src/nsImapIncomingServer.cpp#1410

Summary: With or without the pref set (which gets set on every start unless I'm missing something) I can't reproduce the issue.

I was going to backout bug 1175446 from beta since I prefer not to ship a beta that will make 10.000 Gmail users yell at us, but unless I can reproduce the problem, I'm not really up for a backout.

Any more information would be greatly appreciated.

I think it might be relevant that I have three different Gmail accounts configured.

After quitting from Thunderbird, editing my prefs.js to remove the trash_folder_name preference from all three accounts, and restarting Thunderbird, I see interesting, different behavior in the three Gmail accounts.

In first two listed Gmail accounts, the "Trash" folder at the top level underneath the account name has the special Trash icon, whereas the "Trash" folder inside "[Gmail"] does not. However, in the third, most recently added Gmail account, there is no Trash folder at the top level, and the one underneath "[Gmail"] has the special Trash icon.

I'm not sure where those "Trash" folders at the top level came from. I don't think I created them. Perhaps an earlier, buggier (with respect to Gmail handling) version of Thunderbird created them, or perhaps one of the other mail clients I use created them. In any case, until recently they were (correctly) ignored by Thunderbird.

If I edit the account settings to explicitly specify the correct Trash folder under "[Gmail]" for all three accounts, then delete the two bogus Trash folders at the top level, then exit from Thunderbird, remove the trash_folder_name preferences from prefs.js, and restart, then deleting messages works properly.

So my guess is that something has changed recently with regards to the "discovery" you mentioned which caused Thunderbird to switch from using "[Gmail]/Trash" by default to using "Trash" by default if it exists, which is going to bite anyone who has a "Trash" folder at the top level, which isn't actually the real Gmail Trash folder.

Regarding your question about what "All Mail" is, note that IMAP Folders aren't really "folders" as far as Gmail is concerned, they're message labels. So that's why you see messages in "All Mail" that aren't visible in any other folders. A message doesn't get removed from "All Mail" unless you actually delete it (move it to [Gmail]/Trash), at which point it immediately disappears from all IMAP folders it was in.

Thanks for the feedback. I already seem to have the working setup:

Inbox
[Gmail]
 - Drafts
 - Trash (with proper icon)
 - etc.

So I think I can sleep soundly tonight and not back anything out.

You have a working setup. We have no way of knowing how many people don't. I'm quite nervous about this, but I guess it's probably ok as long as we fix it before it goes out of beta.

I don't see a problem with deleting things with any existing gmail accounts in a couple profiles. I also created a new gmail account in an existing profile and it also works fine and deletes to the inner [Gmail]/Trash. This is with a recent trunk build.

I have the outer Trash folder (not under [Gmail]) that I'm pretty sure I created while experimenting with gmail trash behavior. Those can be deleted optionally. I've also read that the outer Trash may be created by other clients accessing the gmail account and that the actual label name at gmail is [Imap]/Trash. I also found that [Imap]/Trash might have a special ability to "immediately" deleted anything placed into it almost like a black hole, but that may be an urban legend, and it just seems to behave for me like any other user created folder.

Also, I should mention that on my gmail accounts I don't have the mail.server.serverX.trash_folder_name in prefs.js for any of them and the delete to [Gmail]/Trash works fine.

But curious why Jonathan's gmail failed to completely delete before he tweaked it.

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

So I opened one of them and looked at my prefs. mail.server.server11.trash_folder_name was set to [Gmail]/Trash. So I reset it.

Jorg, do you mean you "reset" it in config editor? When I reset it (or if I just remove the line from prefs.js) I see "Choose Folder" in server setting for the trash destination.

I deleted a bunch of test e-mails from "All Mail" and they all went to the Trash and didn't bounce back. BTW, can someone explain to me what "All Mail" is? I thought it was a collection of all mail from all other folders, but it had some mail not seen in any other folder.

I restarted TB, and the pref came back. Most likely TB talks to the Gmail IMAP folder and asks about the folders and stores the pref for the trash folder. That happens here during discovery:
https://searchfox.org/comm-central/rev/90d756d83214006e9ddc9e6de13dc138bd478af3/mailnews/imap/src/nsImapIncomingServer.cpp#1410

I don't see it come back in the prefs.js or in the config editor. But the [Gmail]/Trash still works.

Summary: With or without the pref set (which gets set on every start unless I'm missing something) I can't reproduce the issue.

I don't see a problem either but there are probably variations that we could be missing, e.g., whatever Jonathan saw.

None of my top level Trash folders had the trash icon like Jonathan saw. However, the new feature allows a user to select them as the trash destination if wanted (or any other user created folder).

Ok, I can see this as a possible problem: A user with pre-70b had selected a not [Gmail]/Trash folder as the trash destination. This really doesn't work and [Gmail]/Trash remains the destination even though the other folder is configured. Then when a 70b user runs TB with this setup, the not [Gmail]/Trash folder becomes the trash destination. Jonathan saw something like this when the "outer" Trash had the trash icon (but he says it was never configured as such). So in this case the user needs to "reset" the trash_folder_name setting or explicitly set the trash folder setting to [Gmail]/Trash in server settings to ensure that the default [Gmail]/Trash remains the trash destination.

Something about this should be in the release notes.

Yes, "reset" in the config editor sets the pref to its default so it won't be stored in prefs.js. I've changed the release notes to read:
https://www-stage.thunderbird.net/en-US/thunderbird/70.0beta/releasenotes/
Fixed: Gmail doesn't allow a non-standard trash folder. Note: If message deletion on Gmail doesn't work, make sure the Trash folder is inside the [Gmail] folder and is selected in the account settings.

Sorry, I'm in a rush this Saturday(!) morning, if you want me to do anything else, let me know. I don't see this as an issue for holding up the beta release since there is a clear way to fix non-functioning cases. We can look into some "auto-fix" for the next ESR if we can reliably reproduce the issue. My Gmail account was older than 10 years, and it was working fine.

Perhaps if we correctly used the sever directory of [Gmail} then half of this fiddling about [gmail]\trash would not exist. I have never understood why Thunderbird does not automatically include the server directory correctly.

I am able to reproduce this issue in a brand new profile in Linux nightly with the following steps:

  1. Make sure that the Gmail account has a top-level "Trash" IMAP folder in addition to the one inside "[Gmail]".
  2. Add the Gmail account to the new profile, accepting default settings.
  3. Enable Lightning and restart (not sure if this is relevant, just mentioning it for completeness).

After just these three simple steps:

  1. Thunderbird decides that the top-level "Trash" folder is the correct Trash folder to use, rather than the one inside "[Gmail]".
  2. If a message is in "All Mail" and another IMAP folder (or Inbox) and I delete it from "All Mail", then it disappears from "All Mail" and immediately comes back, and it never disappears from the other folder.
  3. If a message is in "All Mail" and another IMAP folder (or Inbox) and I delete it from the other folder, then it disappears from the other folder but not from "All Mail".

None of this is correct behavior.

From this and my prior experience with my old profile, it seems clear to me that there's a good chance that anyone who has an IMAP folder called "Trash" is likely to run into problems when the upgrade to a Thunderbird with the patch from bug 1175446 in it.

My concern with the proposal to "fix this" with release notes for the beta is that there's a good chance that this problem will be invisible to people who experience it. Deleted messages aren't really being deleted; they're instead being moved into the top-level "Trash" folder. But the user isn't going to notice this because they're never going to look in their top-level "Trash" folder and because they won't see that the messages aren't being deleted unless they happen to look in "All Mail", which they probably don't do very often. So they could go a long time thinking their deleting messages that aren't actually getting deleted, and then when they discover that they're going to have a mess to clean up.

If they're lucky, they can clean it up by changing their Trash folder to [Gmail]/Trash in their account settings and then deleting all the messages in the top-level Trash folder, which should do the right thing. But it won't do the right thing unless they do it in exactly that order, so if e.g. they just deleted the messages from the Trash folder without first adjusting their account settings then they'll still remain in "All Mail". It also won't do the right thing if, e.g., they have trash expiration set up and some of the messages have already been removed automatically from that Trash folder.

There's one thing here that I want to be sure people understand: the correct behavior WRT a Gmail account is that when you move a message to [Gmail]/Trash it disappears from all folders it's in. That's the behavior that people expect, and IMO that behavior should be preserved as the default.

TL;DR I'm really worried that this is going to have a larger impact than people here are assuming and make trouble for a lot of beta users with Gmail accounts.

(In reply to Jonathan Kamens from comment #14)

I am able to reproduce this issue in a brand new profile in Linux nightly with the following steps:

Today I see something similar to what you described on an old account (the new account looks OK). I haven't read you full comment yet but when I started tb I had a top level Trash that I didn't remember creating (in fact, I remember deleting it at gmail site!) and it was the trash destination. So I need to look at this closer.

P/S: Yesterday when I tested I realized, after posting above, that I didn't have the change actually pulled in. Then I pulled comm and the build failed so had to pull mozilla too. And now today have a successful build with the change and see the problem.

In the imap log I didn't see the top level Trash being created. Also top level Trash is not marked as \Trash in the xlist response, but inner one is.

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

Yes, "reset" in the config editor sets the pref to its default so it won't be stored in prefs.js. I've changed the release notes to read:
https://www-stage.thunderbird.net/en-US/thunderbird/70.0beta/releasenotes/
Fixed: Gmail doesn't allow a non-standard trash folder. Note: If message deletion on Gmail doesn't work, make sure the Trash folder is inside the [Gmail] folder and is selected in the account settings.

The bug reporter (elmhaxx) wants to try the beta. The download link seems to point to a 69 beta. (Sorry, partial message got sent when I added elmhaxx to CCs.)

Get if from here, it hasn't been released yet and I'm still considering doing the backout:
https://archive.mozilla.org/pub/thunderbird/candidates/70.0b1-candidates/build1/

All we did in bug 1175446 was to pull out a bit of Gmail-specific code, 8 lines, the reset are indentation changes:
https://hg.mozilla.org/comm-central/rev/b1e49a0013b6#l1.16

(In reply to Jonathan Kamens from comment #14)

I am able to reproduce this issue in a brand new profile in Linux nightly with the following steps:

  1. Make sure that the Gmail account has a top-level "Trash" IMAP folder in addition to the one inside "[Gmail]".
  2. Add the Gmail account to the new profile, accepting default settings.
  3. Enable Lightning and restart (not sure if this is relevant, just mentioning it for completeness).

Yes, the does cause the outer Trash to be used for trash destination.

After just these three simple steps:

  1. Thunderbird decides that the top-level "Trash" folder is the correct Trash folder to use, rather than the one inside "[Gmail]".
  2. If a message is in "All Mail" and another IMAP folder (or Inbox) and I delete it from "All Mail", then it disappears from "All Mail" and immediately comes back, and it never disappears from the other folder.

Yes, the "deleted" message was moved to the outer Trash. But to gmail its just a normal folder so it stays is still in "All Mail".

  1. If a message is in "All Mail" and another IMAP folder (or Inbox) and I delete it from the other folder, then it disappears from the other folder but not from "All Mail".

None of this is correct behavior.

From this and my prior experience with my old profile, it seems clear to me that there's a good chance that anyone who has an IMAP folder called "Trash" is likely to run into problems when the upgrade to a Thunderbird with the patch from bug 1175446 in it.

And sometimes the outer Trash "magically" seems to appear!

My concern with the proposal to "fix this" with release notes for the beta is that there's a good chance that this problem will be invisible to people who experience it. Deleted messages aren't really being deleted; they're instead being moved into the top-level "Trash" folder. But the user isn't going to notice this because they're never going to look in their top-level "Trash" folder and because they won't see that the messages aren't being deleted unless they happen to look in "All Mail", which they probably don't do very often. So they could go a long time thinking their deleting messages that aren't actually getting deleted, and then when they discover that they're going to have a mess to clean up.

If they're lucky, they can clean it up by changing their Trash folder to [Gmail]/Trash in their account settings and then deleting all the messages in the top-level Trash folder, which should do the right thing. But it won't do the right thing unless they do it in exactly that order, so if e.g. they just deleted the messages from the Trash folder without first adjusting their account settings then they'll still remain in "All Mail". It also won't do the right thing if, e.g., they have trash expiration set up and some of the messages have already been removed automatically from that Trash folder.

There's one thing here that I want to be sure people understand: the correct behavior WRT a Gmail account is that when you move a message to [Gmail]/Trash it disappears from all folders it's in. That's the behavior that people expect, and IMO that behavior should be preserved as the default.

TL;DR I'm really worried that this is going to have a larger impact than people here are assuming and make trouble for a lot of beta users with Gmail accounts.

I pointed out the same problems (other than the outer Trash problem which you just found) in the original bug here: bug 1175446 comment 99.

It was also suggested in the original bug and related bugs that a change to allow any gmail folder to be tb's trash folder should only be enabled with a pref due to the issues you point out and other possible localization issues that are unclear to me.

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

Get if from here, it hasn't been released yet and I'm still considering doing the backout:
https://archive.mozilla.org/pub/thunderbird/candidates/70.0b1-candidates/build1/

Thanks, I was looking under releases. I sent the reporter the link via email.

I will try to figure out what is going on with the "outer Trash" problem.

(In reply to Matt from comment #13)

Perhaps if we correctly used the sever directory of [Gmail} then half of this fiddling about [gmail]\trash would not exist. I have never understood why Thunderbird does not automatically include the server directory correctly.

In advanced server setting you can set IMAP server directory to [Gmail]and restart tb. When it comes up you only see Inbox and the folders under [Gmail] in a flat structure and you don't see [Gmail] grey folder anymore. Also, the Trash that was under [Gmail] is the the trash destination folder as it should be.
However, doing this you don't see any user created folders at the top level (peers of Inbox) anymore.
I've seen this suggested but don't know if there other problems with doing this. But by "hiding" the top level Trash, it seems to fix the problem Jonathan pointed out. Of course, it comes back when you go back the default advance server setting.
Matt, are you suggesting this should be the default setup for gmail accounts? If so, a user may still want to select an alternate folder for trash destination since the default [Gmail]/Trash folder is subject to 30 day deletion (which is the main reason this change is wanted even though emails are not really "deleted" when an alternate trash folder is selected).

Yes I am suggesting it should be default. This whole greyed out [Gmail] structures only exists because we do not set the server directory appropriately.

Historically Thunderbird honoured the folder gmail offered when asked for the trash folder. Now we are choosing to make up another folder that is trash (bug 1175446) and in all honesty break the synchronisation strategy IMAP is based on. All because users do not like the Google mandated retention policy for trash. If you do not like your providers retention policy and they will not change it for you, find a provider that will.

Another significant issue here I think is, that is that much of this is about fighting the Gmail way. All mail is an unfiltered view into the gmail store. ALL other folders are really just a fiction, being generated on the fly based on a label connected to the email. Germain to the issue is that Google offers options to modify what happens when the user deletes a message in IMAP. We are not adequately handling the three options google offer their users I do not think.

When a message is marked as deleted and expunged from the last visible IMAP folder:
Archive the message (default)
Move the message to the Trash
Immediately delete the message forever

So is this a bug, or expected, behaviour based on a non default or default deletion setting in GMail. Gmails "all mail" folder is it's archive, so unlike the other folders I would expect it to behave differently to a delete command that the other folders do if the setting is default. So the user deleting mail from the all mail folder in imap would usually cause it to be archived, so it appears in the all mail folder.

But really I think this particular bug is about a conflict between Gmails settings and Thunderbird. What is appropriate for Thunderbird really depends on your settings. Are you archiving on Gmail or Immediately deleting forever at the Google end of things. Using this "new" approach the email no longer meets the deleting threshold in Google because it still retains a label (whatever_your_trash_is_called) so it belongs in all mail. Obviously this would manifest as either a deletion failure, or an immediate "replacement" as the google account has that email in it. EXactly the observed result here.

Solution: Back out bug 1175446 and rethink the whole strategy based on how Google implemented their psuedo IMAP server. There is nowhere in a google account to hold mail deleted from the "all mail" folder, except the IMAP designated trash.

I have a fix for the immediate problem pointed out in this regression bug. I need to test it a bit more and then submit it. Then we can decide whether to back out the whole thing or keep it, if that's OK. I should have the fix submitted sometime today.

Thanks. My idea was to restore the code we removed in bug 1175446 but instead of re-adding if (isGMailServer) { instead do something like:

rv = GetUnicharValue(PREF_TRASH_FOLDER_PATH, retval);
if (isGMailServer && (NS_FAILED(rv) || retval.IsEmpty())) {

That would restore the old behaviour if the pref isn't set. But I came up with this idea walking down the street, so it may be completely wrong ;-)

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

Thanks. My idea was to restore the code we removed in bug 1175446 but instead of re-adding if (isGMailServer) { instead do something like:

rv = GetUnicharValue(PREF_TRASH_FOLDER_PATH, retval);
if (isGMailServer && (NS_FAILED(rv) || retval.IsEmpty())) {

That would restore the old behaviour if the pref isn't set. But I came up with this idea walking down the street, so it may be completely wrong ;-)

Wow, it works! My change was first to modify GetTrashFolderName() to return "[Gmail]/Trash" as the default when the pref is empty and server is gmail. That worked but I didn't like the hardcoded string.

Then I decided to do like your idea except I also tried to get rid of the GetTrashFolderName() call before the loop and replace it with GetUnicharValue() and check again for "isGMailServer" down below. That also worked but it was not real pretty.

But your idea to keep the GetTrashFolderName() call and just add the GetUnicharValue() using the original code mostly as-is seems to work great!

I've only tested with the single gmail profile that Jonathan came up with so I still need to check that non-gmail accounts allow the setting of arbitrary trash folders. Looks like it should since the "else" clause will occur for non-gmail still.

So like this? Just a backout with the extra 3 lines. So the net effect is re-adding this:

           if (trashFolder) {
+            // If we're a gmail server, we clear the trash flags from folder(s)
+            // without the kImapXListTrash flag. For normal servers, we clear
+            // the trash folder flag if the folder name doesn't match the
+            // pref trash folder name.
+            nsAutoString retval;
+            rv = GetUnicharValue(PREF_TRASH_FOLDER_PATH, retval);
+            if (isGMailServer && (NS_FAILED(rv) || retval.IsEmpty())) {
+              nsCOMPtr<nsIMsgImapMailFolder> imapFolder(
+                  do_QueryInterface(trashFolder));
+              int32_t boxFlags;
+              imapFolder->GetBoxFlags(&boxFlags);
+              if (boxFlags & kImapXListTrash) {
+                continue;
+              }
+            } else {
             // Store the trash folder path. We maintain the full path in the
Assignee: nobody → jorgk
Attachment #9091312 - Flags: review?(gds)
Comment on attachment 9091312 [details] [diff] [review] 1579304-gmail-fix.patch Review of attachment 9091312 [details] [diff] [review]: ----------------------------------------------------------------- That works for me. Also tested on non-gmail account.
Attachment #9091312 - Flags: review?(gds) → review+

OK, I'll push this, then Jonathan can try it in tomorrow's Daily. Also, it maintains the custom Trash if desired, right?

Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

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

OK, I'll push this, then Jonathan can try it in tomorrow's Daily. Also, it maintains the custom Trash if desired, right?

Yes, you can assign an arbitrary folder in gmail or other servers to be trash and the icon appears and "deleted" messages are moved from the source folder to there.

Other then the pro and con arguments for doing this change at all, this issue still exists that I mentioned in comment 11:

Ok, I can see this as a possible but rare problem: A user with pre-70b had selected a not [Gmail]/Trash folder as the trash destination. This really doesn't work and [Gmail]/Trash remains the destination even though the other folder is the value of pref "trash_folder_name". Then when a 70b user runs TB with this setup, the not [Gmail]/Trash folder becomes the trash destination. So in this case the user needs to "reset" the trash_folder_name setting in config editor or explicitly set the trash folder setting to [Gmail]/Trash in server settings to ensure that the default [Gmail]/Trash remains the trash destination.

Something about this should be in the release notes.

Target Milestone: --- → Thunderbird 71.0
Comment on attachment 9091312 [details] [diff] [review] 1579304-gmail-fix.patch Yes, I'll adjust the release notes accordingly, but it's a rare case.
Attachment #9091312 - Flags: approval-comm-beta+

Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/5576acbb060f
Revert changes from bug 1175446 but also check the pref. r=GeneSmith

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

Just an observation. Don't think it needs to check for gmail server since other servers support xlist and special-use responses, but not suggesting it be changed as part of this bug.

           if (trashFolder) {
+            // If we're a gmail server, we clear the trash flags from folder(s)
+            // without the kImapXListTrash flag. For normal servers, we clear
+            // the trash folder flag if the folder name doesn't match the
+            // pref trash folder name.
+            nsAutoString retval;
+            rv = GetUnicharValue(PREF_TRASH_FOLDER_PATH, retval);
+            if (/*isGMailServer &&*/ (NS_FAILED(rv) || retval.IsEmpty())) {  // Probably don't need to check for gmail server
+              nsCOMPtr<nsIMsgImapMailFolder> imapFolder(
+                  do_QueryInterface(trashFolder));
+              int32_t boxFlags;
+              imapFolder->GetBoxFlags(&boxFlags);
+              if (boxFlags & kImapXListTrash) {
+                continue;
+              }
+            } else {
             // Store the trash folder path. We maintain the full path in the
Comment on attachment 9091312 [details] [diff] [review] 1579304-gmail-fix.patch In case we backport bug 1175446.
Attachment #9091312 - Flags: approval-comm-esr68?

Release notes now say:
Gmail doesn't allow a non-standard trash folder. Note: If non-standard trash folder was selected previously in the account settings, this setting will now take effect which may be unexpected.

Issue does appear to be fixed with 2019-09-09 Daily.

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

Release notes now say:
Gmail doesn't allow a non-standard trash folder. Note: If non-standard trash folder was selected previously in the account settings, this setting will now take effect which may be unexpected.

Better?
Previously, gmail accounts ignored a non-standard trash folder selection. Note: If non-standard trash folder was selected previously in the account settings, this setting will now take effect which may be unexpected.

Thanks, Gene, I'll take your version.

Attachment #9091312 - Flags: approval-comm-esr68? → approval-comm-esr68+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: