Closed Bug 1335982 Opened 7 years ago Closed 6 years ago

Thunderbird automatically creates unwanted 'Trash' and other folders on IMAP server when creating a new email account and during start-up of Thunderbird.

Categories

(MailNews Core :: Networking: IMAP, defect)

x86_64
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 59.0

People

(Reporter: linux, Assigned: gds)

References

Details

(Keywords: imap-interop, regression, reproducible)

Attachments

(4 files, 4 obsolete files)

Attached file More info
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20170131111754

Steps to reproduce:

When I create new IMAP mail user, Thunderbird creates a unwanted additional 'Trash' folder on the server. The server Admin then deletes the 'Trash' directory. When I restart start up Thunderbird, the unwanted 'Trash' folder is created again.

This does Not happen with Thunderbird v. 31.8 and earlier.


Actual results:

Thunderbird versions later than 31.8.0 automatically create a second (unwanted) Trash folder:
root@server-2:/var/vmail/c5ace.com/test/Maildir#
/.INBOX
/.INBOX.Archives
/.INBOX.Drafts
/.INBOX.Junk
/.INBOX.Sent
/.INBOX.Templates
/.INBOX.Trash
/.Trash <--- Unwanted Folder

There should be a feature to disable automatic directory creation during creation of a user account and startup of Thunderbird.


Expected results:

The IMAP server's directory structure is:
root@server-2:/var/vmail/c5ace.com/test/Maildir# 
/.INBOX
/.INBOX.Archives
/.INBOX.Drafts
/.INBOX.Junk
/.INBOX.Sent
/.INBOX.Templates
/.INBOX.Trash
You probably meant to pick version 45?
Component: Untriaged → Account Manager
Version: 46 Branch → 45 Branch
(In reply to Wayne Mery (:wsmwk, NI for questions) from comment #1)
> You probably meant to pick version 45?

I tried all versions supported by Gentoo, 45.6.0-r1 and 45.7.0.  They have the same problem.
Bug still exist with Thunderbird 53.4.0.

There is a IMAP account for testing:
server: mail.c5ace.com
login: test@c5ace.com
Passwd: Thunderbird
Webmail: www.c5ace.com/webmail
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
Version: 45 Branch → 52 Branch
Tested latest Sylpheed and Evolution. They do not create unwanted trash folders on our IMAP server.
As a quick work-around I would suggest that you un-subscribe "Trash". I tried that but it has no effect; trash folder still appears. I don't see a hidden preference that might affect this. I will check the code to see why Trash folder is always created.

The only way I can un-subscribe/hide the Trash folder is to set the delete method under server settings to "just mark it as deleted". Only then does the un-subscribed Trash folder become hidden.

I create a new Trash under Inbox (like yours) and tried to delete the old root level Trash and server reports that I can't delete a "default" folder. So, for my server, apparently the Trash folder at root level is created by the server and not tb. I need to look closer, but are you 100% sure your server is not creating/keeping the unwanted Trash folder?

Also, now I get no tb menu for deleting the Trash folders. Also, can't rename them. So again, I need to look closer.
TB 31.8.0 and later works for me like this:
1.) Create and set up directory structure for the new user IMAP account on the server.
2.) Start TB and create new user account.
3.) Go to Account Settings -> Server Settings and set 'Trash' to 'Inbox->Trash'
4.) Go to Account Settings -> Copies & Folders and set Sent, Archives, Drafts, Templates folders, tick 'Other' and set the folders to Inbox -> Sent, etc.
5.) Go to Account Settings -> Junk Settings, tick 'Enable adaptive Junk mail controls for this account', tick 'Move new messages to:'. tick 'Other' and set to Inbox -> Trash.  
5.) Go to Account Settings -> Junk Settings, click 'Global Junk Preferences' -> 'Security' tick 'When I mark messages as junk' and tick 'Move them to the account's "Junk" folder.
  
Now restart TB, view the accounts folder list. The list should show the appropriate icons and the unwanted Trash folder should show the folder icon. Right click and delete the unwanted Trash folder. This is now moved to Inbox -> Trash. Right click and 'Empty Trash' and restart TB. 

With TB 31.8.0 no more unwanted 'Trash Folder'. With later versions of TB, the unwanted trash folder reappears a few seconds after the next start of TB.

It may be that the code run on start-up of TB that reads and creates the folder structure from the IMAP server handles Trash differently and creates the unwanted Trash folder. Maybe just because the Trash folder location is set on the 'Server Setting' page instead of 'Copies & Folders'.
Further more, the mail on Android and Iphone do not create unwanted Trash folders.
I've attached a debugger and can see what is going on but still not sure why. I am calling my trash folder "RoundFile" just to give it a unique name. If I configure delete destination as Inbox/Roundfile, after I delete the original root level Trash it looks OK. But on restart another root level RoundFile is created and is subscribed. It also changes the server trash destination setting to root level RoundFile. There is a trash_folder preference variable that is stored and is originally "Inbox/RoundFile". But when it is used, only the RoundFile part is used and tb creates the root level folder with that name. Also, the pref var trash_folder gets changed to just RoundFile.
To delete the new root level RoundFile you have to set the delete method to "just mark it as deleted"; otherwise, there is no "delete" menu selection.

Definitely looks like a bug. I haven't compared to older version to see what changed but will. Still debugging.
TB 31.8 and lower on Linux work OK after setup and configuration as previously described. The bug appeared between TB 31.8 and TB 38.8 or TB 45.2.

If TB would have been written in simple 'C', I could do a 1 to 1 compare of each function or single step from start of execution. C++ and what ever other language used to create TB is to complex and convoluted for me (73yo) to comprehend. If you have the know-how and facilities, maybe try TB 31.8 vs TB 38.8 and TB 46.2. and compare the changes to the code.
(In reply to Elmar Haag from comment #3)
> Bug still exist with Thunderbird 53.4.0.
> 
> There is a IMAP account for testing:
> server: mail.c5ace.com
> login: test@c5ace.com
> Passwd: Thunderbird
> Webmail: www.c5ace.com/webmail

Thanks for the test account (I just now noticed it!). It works and I see the problem with it but I also see the problem on my own accounts. I can fix the problem by removing one line of code. However, that line and the function has been there way before version 38. Also, there is one change in this area after 38.8 but reverting it doesn't fix the problem and causes another problem (see bug 1156669).
Can you check TB 31.8 and compare the relevant code with the code in later versions such as 52.4 or 52.5?
Actually the offending line was put in during release 38 but wasn't in 31.8 that you say works OK (see bug 558659). However, the associated patch fixes a lot of other issues -- but breaks trash under inbox for you :(. I need to look closer and see what can be done. However, since this requires a fix or new feature it won't be quickly released, except as a beta.
As a workaround, can you just have the "trash" folder at root level outside of inbox and at the same level as inbox? Why does trash have to be under inbox?

Using the test@c5ace account I made a changed to a flat folder structure:

Inbox
Drafts
Templates
Sent
Archives
Junk
Trash

and it seems to work. The hard part was I got two trash folders, one under root and the other under Inbox, both called Trash. Getting rid of the one under Inbox was a bit tricky but I did it in tb. Also, the webmail now shows the new flat folder structure.
Attached patch trash_folder.patch (obsolete) — Splinter Review
Well, I think I have a 1st cut proposed change that should not affect the previous fixes and repairs the regression identified by this bug. The problem is that obtaining the trash folder name from the trash url leaves off a potential enclosing mailbox. For example if the trash url is "imap://t.testov%40argus-spectr.ru@mail.argus-spectr.ru/INBOX/RoundFile" it thinks the mailbox is just "RoundFile" and not INBOX/RoundFile. This cause the creation of the root level RoundFile later on which is the observed problem. This is because the search of the "leaf" position uses RFindChar() and finds the last "/" as the delimiter and returns just "RoundFile". My changes uses FindChar() instead and searches for the "//" and then searches for the next "/" to return the correct string "INBOX/RoundFile". 

A possible issue with this might be that a folder url could contain other intermediate "/" characters, but I don't think they do; but I will check closer on this.

Elmar, you might be able to manually apply this patch to your Gentoo source for the latest TB and see if this fixes the problem for you. You can leave out the "printf("gds: ...)" I have added for info print-out if you want. (I'm assuming Gentoo still supports user compiling of installed apps.)

With this fix I can have trash defined under Inbox and no trash at root level is created on tb restarts. Also, I think on account creation, if the server has trash under inbox, no extra root level trash folder will be created (I haven't tried this). But even if it does, just configure tb to use inbox/trash as trash and the extra root level trash may now be deleted easily (should have no trash icon on it).
(In reply to gene smith from comment #13)
> 
> A possible issue with this might be that a folder url could contain other
> intermediate "/" characters, but I don't think they do; but I will check
> closer on this.
> 

I created an account with user name gene/d/smith on my local Zimbra server and tb converts the slashes to %2F in the url string it creates:

imap://gene%2Fd%2Fsmith@192.168.1.23/Trash

So searching for the / before the trash folder string from the left (3rd actual /) should work.

Note: On account creation, tb warns about the strange username but still allows it.
I take care of mor then 20 Gentoo boxes. Will try to apply the patch to my own box. If it works OK, will cause the patch to be installed when upgrading to the latest TB in my local repository. This will take a few days.

I don't understand why the creation of the Trash folder is handled differently from the Draft and Send folders.
That sounds good! No idea about the other "system" folders. The handling for trash seems to be totally separated from drafts, sent, junk and templates. Just glad they work OK for you. Anyhow, if my changes work for you, I will remove the printf's and submit a formal patch. 
By the way, do any of your users have a "/" in their username?
Just wait a few days until I am able to apply the patch. 
Non of my users have a "/" in their name. Their login name (username) is their email address like "test@c5ace.com". I don't think that dovecot allows "/" in login names (usernames).
Ok, no problem. Not trying to hurry you on this.
I did test the fix against a Zimbra imap account with slashes in the user name (and trash url) and it worked. Thanks for your help in finding and fixing this bug!
Bug 1175446 seems to be another unfixed regression associated with this same area of code.

Elmar, Do you possibly use a non-English version to tb? If so, since this code involves localization, any test you do will provide better information since I have only tested the default English version.
Gene, I am in Australia. We use the US version with local.gen:
en_AU ISO-8859-1
en_AU.UTF-8 UTF-8
This should not make any difference to TB as it only affects the display of date, time and punctuation format of the system.
I installed and tested TB 52.4.0 with the patch applied.

The result:
The patch works PROVIDED if I upgrade from TB 31.8.0. If I create a new account to connect to an existing IMAP, the unwanted Trash folder is created. This can be removed. Then deleted items end up in Never Never land instead of INBOX.Trash. Also the Icon for the Trash folder is a Icon for a plain folder instead of the Trash icon.

I do believe that the problem may be caused by TB contacting the IMAP server after or in parallel to creating the default Trash folder. 

To test this:
- Have a clean IMAP account with the INBOX.Trash, etc, structure and without the unwanted Trash folder.
- Delete ~/.thunderbird. 
- Create and set up directory structure for the new user IMAP account on the server.
- Start TB and create new user account.
- Go to Account Settings -> Server Settings and set 'Trash' to 'Inbox->Trash'
- Go to Account Settings -> Copies & Folders and set Sent, Archives, Drafts, Templates folders, tick 'Other' and set the folders to Inbox -> Sent, etc.
- Go to Account Settings -> Junk Settings, tick 'Enable adaptive Junk mail controls for this account', tick 'Move new messages to:'. tick 'Other' and set to Inbox -> Trash.  
- Go to Account Settings -> Junk Settings, click 'Global Junk Preferences' -> 'Security' tick 'When I mark messages as junk' and tick 'Move them to the account's "Junk" folder. 

Delete the unwanted Trash Folder. This should move the Trash Folder as subfolder to Inbox->Trash (Does not happen). Empty the Inbox->Trash folder (No "Empty Trash" menu item, no Trash icon).

Stop TB and delete .Trash folder and subscription of .Trash folder from the server. Start TB, check the Trash icon, and test by deleting a message and empty the Trash Folder (Does not work).

Maybe have a look at Sylpheed and/or maybe disable automatic creation of trash and other folders when creating and connecting to a mail box on an IMAP server or make this a option.
(In reply to Elmar Haag from comment #21)

Hi Elmar, sorry it didn't work like you hoped.

> I installed and tested TB 52.4.0 with the patch applied.
> 
> The result: The patch works PROVIDED if I upgrade from TB 31.8.0.

Not sure I understand why upgrade from that version matters, especially since it sounds like you are deleting all the ~/.thunderbird files.

Here's what I did and it works. I first deleted my existing c5ace account with tb, including the account data. This removes everything in the ~/.thunderbird profile under MailNews related to c5ace.

Using the account creation wizard, I re-create the account and once it indicates all is OK I hit "Advanced Settings" instead of "Done".

Now go to the new c5ace account Server settings and set "When I delete a message just mark it as deleted". The default setting is move to trash. Make sure the default is *not* selected to avoid extra Trash folder creation!

Now click on Inbox for the account, which should be the only thing present. You may need to subscribe Inbox and the internal folders (including Trash) so see them. I had to do this.

Expand the folders and you should only see folders under inbox (no new trash created).

Do this as you describe:

> - Go to Account Settings -> Server Settings and set 'Trash' to 'Inbox->Trash'
**Also, be sure to now set radio button "When I delete a message move it to trash".**
> - Go to Account Settings -> Copies & Folders and set Sent, Archives, Drafts,
> Templates folders, tick 'Other' and set the folders to Inbox -> Sent, etc.
> - Go to Account Settings -> Junk Settings, tick 'Enable adaptive Junk mail
> controls for this account', tick 'Move new messages to:'. tick 'Other' and
> set to Inbox -> Trash.  
> - Go to Account Settings -> Junk Settings, click 'Global Junk Preferences'
> -> 'Security' tick 'When I mark messages as junk' and tick 'Move them to the
> account's "Junk" folder. 
> 

You will now see the expected icons on most of the folders you set above, especially Inbox/Trash.

Your trash should go to Inbox/Trash, drafts to Inbox/Drafts, sent mail to Inbox/Sent, etc.

You can stop and start tb (multiple times) and the annoying extra trash folder will not appear.
So, when I use this method it works fine. I have more comments/question on your method below.

> If I create a new
> account to connect to an existing IMAP, the unwanted Trash folder is
> created. This can be removed. Then deleted items end up in Never Never land
> instead of INBOX.Trash. Also the Icon for the Trash folder is a Icon for a
> plain folder instead of the Trash icon.
> 
> I do believe that the problem may be caused by TB contacting the IMAP server
> after or in parallel to creating the default Trash folder. 
> 
> To test this:
> - Have a clean IMAP account with the INBOX.Trash, etc, structure and without
> the unwanted Trash folder.
> - Delete ~/.thunderbird. 
> - Create and set up directory structure for the new user IMAP account on the
> server.
> - Start TB and create new user account.
> - Go to Account Settings -> Server Settings and set 'Trash' to 'Inbox->Trash'
> - Go to Account Settings -> Copies & Folders and set Sent, Archives, Drafts,
> Templates folders, tick 'Other' and set the folders to Inbox -> Sent, etc.
> - Go to Account Settings -> Junk Settings, tick 'Enable adaptive Junk mail
> controls for this account', tick 'Move new messages to:'. tick 'Other' and
> set to Inbox -> Trash.  
> - Go to Account Settings -> Junk Settings, click 'Global Junk Preferences'
> -> 'Security' tick 'When I mark messages as junk' and tick 'Move them to the
> account's "Junk" folder. 
> 
> Delete the unwanted Trash Folder. This should move the Trash Folder as
> subfolder to Inbox->Trash (Does not happen). Empty the Inbox->Trash folder
> (No "Empty Trash" menu item, no Trash icon).

This seems weird. At this point, following your procedure the Inbox/Trash should have an icon and a delete trash right-click menu item. You may need to collapse and then expand the c5ace account using the ">" icon to force a refresh of the folder states after a changes is made. Worst case, maybe restart tb. After this, you should see the trash icon on Inbox/Trash and the outer Trash folder should appear as a normal folder. Once you see these folder states, you should be able to delete the outer trash folder (again, if it doesn't seem to delete, collaspe/expand the account or restart tb and it should then appear inside Inbox as Inbox/Trash/Trash; then empty trash).

> 
> Stop TB and delete .Trash folder and subscription of .Trash folder from the
> server. Start TB, check the Trash icon, and test by deleting a message and
> empty the Trash Folder (Does not work).

Not sure what you mean by .Trash on the server and how to delete it. Is this done via the webmail?

> 
> Maybe have a look at Sylpheed and/or maybe disable automatic creation of
> trash and other folders when creating and connecting to a mail box on an
> IMAP server or make this a option.

Well, at this point I don't consider the creation of the external trash folder a bug as long as you can set another folder as the real trash and delete the unwanted trash folder (which I think you now can and I seem to be able to do). Again, you can stop the trash creation by selecting "just mark it as deleted" in the server setting by hitting "Advanced" instead of just hitting "Done" in the account wizard.
(In reply to gene smith from comment #22)

Procedure for new installations of TB (no ~/.thunderbird):

- Go to Account Settings -> Server Settings and set 'Trash' to 'Inbox->Trash' and set radio button "When I delete a message: Just mark it as deleted".

Restart TB.
TB now shows the Inbox and sub folders with folder icons.

- Go to Account Settings -> Server Settings, tick  and set 'Trash' to 'Inbox->Trash' 

- Go to Account Settings -> Copies & Folders and set Sent, Archives, Drafts, Templates folders, tick 'Other' and set the folders to 'Inbox -> Sent', etc.

- Go to Account Settings -> Junk Settings, tick 'Enable adaptive Junk mail controls for this account', tick 'Move new Junk messages to:. Tick 'Other' and set to 'Inbox -> Trash'. 
 
- Go to Account Settings -> Junk Settings, click 'Global Junk Preferences' -> 'Security' and tick 'When I mark messages as junk' and tick 'Move them to the account's "Junk" folder. 

Restart TB 
Now the 'Inbox->Trash' folder icon is the trash icon. Deleted messages will be moved to the 'Inbox->Trash' folder and can be deleted by right click -> 'Empty Trash'.

Question:
Does the patch also work with later versions of TB such as 52.5.0?
(In reply to Elmar Haag from comment #23)
> 
> Question:
> Does the patch also work with later versions of TB such as 52.5.0?

I made the patch (not yet formally submitted to TB) against the tb TRUNK version pulled a few weeks ago from mozilla hg repo. So you should be able to apply it to your 52.5 source from Gentoo; definitely if you just do it manually since it's only a few changed lines and if you want to leave out the printf("gds: ...")'s I put in for debug/info. I have only applied and tested with my TRUNK tb.
(In reply to Elmar Haag from comment #21)
> I installed and tested TB 52.4.0 with the patch applied.
> 
> The result:
> The patch works PROVIDED if I upgrade from TB 31.8.0.

I looked closer and see there are a few lines added on Nov 21 to the changed file for 52.5 (after my last pull). However, they are in a completely different area so you should be able to apply the patch and have it work with your 52.5 source from Gentoo just like you did for 52.4. Let me know how it goes.

-gene
(In reply to gene smith from comment #25)

Thanks, 
I will try in a day and let you know.

Elmar
I tried TB 52.5. The patch needs to be changed for TB 52.5

Maybe the patch can be incorporated in future releases of Thunderbird and only automatically create a Trash folder if the IMAP server does not have a Trash folder.

Elmar
(In reply to Elmar Haag from comment #27)
> I tried TB 52.5. The patch needs to be changed for TB 52.5
> 
> Maybe the patch can be incorporated in future releases of Thunderbird and
> only automatically create a Trash folder if the IMAP server does not have a
> Trash folder.

Hi Elmar, was planning on asking you "how's it going" real soon. I am not sure from your response whether the patch worked like you expected or not?

There is already something in tb that checks if a "trash" folder exisit on the server within the top two folder levels. However, to know for sure that a folder is actually THE trash folder it does not go directly by the folder name since in, e.g., Russian, it might be "adfaksdjfasd". Tb looks for an IMAP capability called "SPECIAL-USE" or "XLIST" that indicates the LIST command will return the purpose, in English" of any named folders. 
Looking at the capability response from your imap server, it does not support XLIST but it does support LIST-EXTENDED which allows other variations on the LIST command. This may just mean that SPECIAL-USE is not enabled or configured in your imap server.

Your server returns a NIL string for its ID. However, I do see another indication that your server is Dovecot (after the initial capability response, but no version given). I don't know if you have access to your imap server, but googling "dovecot imap list-extended" brings up how to configure Dovecot and specify which folder is officially your trash folder. Also, googling "dovecot thunderbird list-extended" brings up detailed information about tb supporting this starting with v38.

Re:
https://www.dovecot.org/list/dovecot/2014-December/099203.html
https://wiki.dovecot.org/MailboxSettings

-gene
Hi Gene, 
I confirm:
- The patch works fine with TB 52.4.0. 
- The patch does NOT work with TB 52.5.0. Probably requires minor some minor modifications.

I have access to the mail server.

The mail server was build in 2012 with Debian Squeeze and updates to Wheezy and later to Jessie with ISPconfig on top to provide Web, Mail (Dovecot 2.1.7), DNS, services. 

ISPconfig creates new mail accounts with these IMAP directories:
root@server-2:/var/vmail/c5ace.com/test/Maildir# 
/.Drafts
/.Junk
/.Sent
/.Trash
cur
new
tmp

Then Squirrelmail is used to modify and create hese IMAP directories:
root@server-2:/var/vmail/c5ace.com/test/Maildir#
/.INBOX
/.INBOX.Archives
/.INBOX.Drafts
/.INBOX.Junk
/.INBOX.Sent
/.INBOX.Templates
/.INBOX.Trash


/etc/dovecot/conf.d/15-mailboxes.conf:
##
## Mailbox definitions
##

# NOTE: Assumes "namespace inbox" has been defined in 10-mail.conf. ("namespace inbox" IS DEFINED in 10-mail.conf).
namespace inbox {

 # mailbox name {
    # auto=create will automatically create this mailbox.
    # auto=subscribe will both create and subscribe to the mailbox.
    #auto = no
    # auto = subscribe

    # Space separated list of IMAP SPECIAL-USE attributes as specified by
    # RFC 6154: \All \Archive \Drafts \Flagged \Junk \Sent \Trash
    #special_use =
  #}

  # These mailboxes are widely used and could perhaps be created automatically:
  mailbox Drafts {
    special_use = \Drafts
  }
  mailbox Junk {
    special_use = \Junk
  }
  mailbox Trash {
    special_use = \Trash
  }

  # For \Sent mailboxes there are two widely used names. We'll mark both of
  # them as \Sent. User typically deletes one of them if duplicates are created.
  mailbox Sent {
    special_use = \Sent
  }
  mailbox "Sent Messages" {
    special_use = \Sent
  }

  # If you have a virtual "All messages" mailbox:
  #mailbox virtual/All {
  #  special_use = \All
  #}

  # If you have a virtual "Flagged" mailbox:
  #mailbox virtual/Flagged {
  #  special_use = \Flagged
  #}
}

I compiled TB 52.4.0 with the Gentoo "debug" flag. It appears there are some memory leaks.
You can see the output by logging into test@c5ace.com.

/var/tmp/portage/mail-client/thunderbird-52.4.0/work/thunderbird-52.4.0 is the build directory Thi is automatically deleted when TB has been installed.
(In reply to Elmar Haag from comment #29)
> Hi Gene, 
> I confirm:
> - The patch works fine with TB 52.4.0. 
> - The patch does NOT work with TB 52.5.0. Probably requires minor some minor
> modifications.

Do you mean tb doesn't run with the patch applied? Or do you mean the patch won't apply using whatever procedure you use with Gentoo? 
Can you just manually type in the changes the patch causes and then rebuild? If so, I would think tb would run after the gentoo-build.

> 
> I have access to the mail server.
> 

Good!

> The mail server was build in 2012 with Debian Squeeze and updates to Wheezy
> and later to Jessie with ISPconfig on top to provide Web, Mail (Dovecot
> 2.1.7), DNS, services. 
> 

Dovecot changelog indicate special_use was added at 2.1 so 2.1.7 should have it too.

> ISPconfig creates new mail accounts with these IMAP directories:
> root@server-2:/var/vmail/c5ace.com/test/Maildir# 
> /.Drafts
> /.Junk
> /.Sent
> /.Trash

I assume these are hidden files (or dirs?) under /var/vmail/c5ace.com/test/Maildir# ?
I don't see that these are "under" inbox/INBOX namespace and don't see inbox. But I don't know what these are for. 
Also, don't know what ISPconfig is.

> cur
> new
> tmp
> 
> Then Squirrelmail is used to modify and create hese IMAP directories:
> root@server-2:/var/vmail/c5ace.com/test/Maildir#
> /.INBOX
> /.INBOX.Archives
> /.INBOX.Drafts
> /.INBOX.Junk
> /.INBOX.Sent
> /.INBOX.Templates
> /.INBOX.Trash
> 

OK, these hidden dirs look like the mailbox structure I see in tb.

> 
> /etc/dovecot/conf.d/15-mailboxes.conf:
> ##
> ## Mailbox definitions
> ##
> 
> # NOTE: Assumes "namespace inbox" has been defined in 10-mail.conf.
> ("namespace inbox" IS DEFINED in 10-mail.conf).

Yes, this looks right and is the default set-up for special use all within the "inbox" namespace. I assume your /etc/dovecot.conf includes this file, i.e., has
!include conf.d/*.conf
If so, your mailserver is still not marking any listed mailboxes with the special_use string such as "\Trash" or "\Drafts" so tb not picking these up as your specified Trash, Draft etc. folder.
I have dovecot on my fedora 25 box but it is not running. Maybe I could run a minimal setup and check this locally, unless you can think of something else.

> namespace inbox {
> 
>  # mailbox name {
>     # auto=create will automatically create this mailbox.
>     # auto=subscribe will both create and subscribe to the mailbox.
>     #auto = no
>     # auto = subscribe
> 
>     # Space separated list of IMAP SPECIAL-USE attributes as specified by
>     # RFC 6154: \All \Archive \Drafts \Flagged \Junk \Sent \Trash
>     #special_use =
>   #}
> 
>   # These mailboxes are widely used and could perhaps be created
> automatically:
>   mailbox Drafts {
>     special_use = \Drafts
>   }
>   mailbox Junk {
>     special_use = \Junk
>   }
>   mailbox Trash {
>     special_use = \Trash
>   }
> 
>   # For \Sent mailboxes there are two widely used names. We'll mark both of
>   # them as \Sent. User typically deletes one of them if duplicates are
> created.
>   mailbox Sent {
>     special_use = \Sent
>   }
>   mailbox "Sent Messages" {
>     special_use = \Sent
>   }
> 
>   # If you have a virtual "All messages" mailbox:
>   #mailbox virtual/All {
>   #  special_use = \All
>   #}
> 
>   # If you have a virtual "Flagged" mailbox:
>   #mailbox virtual/Flagged {
>   #  special_use = \Flagged
>   #}
> }
> 
> I compiled TB 52.4.0 with the Gentoo "debug" flag. It appears there are some
> memory leaks.
> You can see the output by logging into test@c5ace.com.

Yes, that looks pretty bad. I don't see any leak warnings when I build the latest version on fedora 25 with debug enabled, with or without the patch.
> Hi Gene, 
> I confirm:
> - The patch works fine with TB 52.4.0. 
> - The patch does NOT work with TB 52.5.0. Probably requires minor some minor
> modifications.

Do you mean tb doesn't run with the patch applied? Or do you mean the patch won't apply using whatever procedure you use with Gentoo? 
Can you just manually type in the changes the patch causes and then rebuild? If so, I would think tb would run after the gentoo-build.

Patch for TB 52.4.0 applies with Gentoo to TB 52.4.0 and works PERFECT with TB 52.4.0.

Patch for TB 52.4.0 does apply to TB 52.5.0 but does NOT work with TB 52.5.0. 
REASON: The code of nsImapIncomingServer.cpp used with TB 52.4.0 is slightly different from the code nsImapIncomingServer.cpp used with TB 52.5.0. The patch changes the wrong lines of code in nsImapIncomingServer.cpp used with TB 52.4.0.
You will have to create a dedicated patch for TB 52.4.0. If I recall correctly, the difference relates to something with gmail.

Will try to modify TB 52.5.0 nsImapIncomingServer.cpp tomorrow.

RE Dovecot Server:
I will build a new server as VirtualBox client, Devuan (Debian without systemd), Dovecot, Apache, DNS, etc. and ISPconfig. You can run this server in VirtualBox on your PC for experimenting. I will also build a Gentoo Xfce Desktop in VirtualBox for experimenting. Both should be finished by 2nd January. 

Are you familiar with Gentoo and Debian?
(In reply to Elmar Haag from comment #31)
> 
> Patch for TB 52.4.0 does apply to TB 52.5.0 but does NOT work with TB
> 52.5.0. 
> REASON: The code of nsImapIncomingServer.cpp used with TB 52.4.0 is slightly
> different from the code nsImapIncomingServer.cpp used with TB 52.5.0. The
> patch changes the wrong lines of code in nsImapIncomingServer.cpp used with
> TB 52.4.0.
> You will have to create a dedicated patch for TB 52.4.0. If I recall
> correctly, the difference relates to something with gmail.
> 
> Will try to modify TB 52.5.0 nsImapIncomingServer.cpp tomorrow.

OK, I think I understand. Your manual mod to the cpp file should work but I will try to send you a patch against the 52.5 version will work correctly. At least it will prevent the extra trash folder creation on tb restart. 

> 
> RE Dovecot Server:
> I will build a new server as VirtualBox client, Devuan (Debian without
> systemd), Dovecot, Apache, DNS, etc. and ISPconfig. You can run this server
> in VirtualBox on your PC for experimenting. I will also build a Gentoo Xfce
> Desktop in VirtualBox for experimenting. Both should be finished by 2nd
> January. 
> 
> Are you familiar with Gentoo and Debian?

I've used debian and virtualbox but not Gentoo. But maybe this won't be necessary. I did run dovecot locally and set up your mailbox structure with everything under Inbox. I also noticed that the special_use flag were not being set into the list responses as I also observed with your server. I found a posting on the dovecot mailing list that indicated you need to add a INBOX. prefix:

So instead of this:

mailbox Trash {
     special_use = \Trash
}

I did this:

mailbox INBOX.Trash {
     special_use = \Trash
}

Putting this on Trash, Drafts, Archive and Sent and restarting dovecot caused the flags I was looking for to now appear in the list response but it didn't help in tb. It still creates the initial Trash folder at the same level as Inbox and it seemed that only Inbox/Drafts was detected and used inside Inbox. When I sent an email it created and saved to Sent at same level as Inbox.

So I have some more debugging to do  :<(
Ok, the problem with my dovecot is that it wasn't advertising the capability SPECIAL-USE so the code in tb that supports this feature never occurred. I had to go into /etc/dovecot/conf.d/20-imap.conf and uncomment and add the line

imap_capability = +SPECIAL-USE

and then restart dovecot. Dovecot now appends this at the end of its capability response. Doesn't seem like I should have to do this but I did.

With your dovecot, it *does* send the SPECIAL-USE capability so it must be configured correctly for this, but, as I pointed out above, you need to add the "INBOX." in front of each of your special_use mailbox specifications in /etc/dovecot/conf.d/15-mailboxes.conf, like this:

namespace inbox {

  mailbox INBOX.Drafts {
    special_use = \Drafts
  }
  mailbox INBOX.Junk {
    special_use = \Junk
  }
  mailbox INBOX.Trash {
    special_use = \Trash
  }
  mailbox INBOX.Sent {
    special_use = \Sent
  }
  mailbox INBOX.Archives {
    special_use = \Archive
  }
}

All this does is cause tb to automatically configure these items so you don't have to set them yourself in the server and copies and destination configuration pages and you should see the proper icon on the folders as soon as you setup the account and then click on Inbox. (Note: there is not special_use for Templates so you may have to configure its destination.)

Also, with the patch applied AND the above mailbox fixes to add "INBOX.", tb should not create the extra Trash at the bottom when you create a new account, it least it doesn't with my dovecot. Without the INBOX. added to at least trash (mailbox INBOX.Trash {...) you will still initially get the extra Trash at the bottom, but once it is deleted and you point tb to your INBOX.Trash destination it shouldn't come back.

I will post the official patch next.
Attached patch 1335982-review-changes0.patch (obsolete) — Splinter Review
This prevents an unwanted Trash folder creation on tb restart when the wanted trash folder is not at root level, e.g., it is at Inbox/Trash.
Attachment #8933943 - Attachment is obsolete: true
Attachment #8937922 - Flags: review?(jorgk)
(In reply to Elmar Haag from comment #29)
> I compiled TB 52.4.0 with the Gentoo "debug" flag. It appears there are some
> memory leaks.
> You can see the output by logging into test@c5ace.com.
> 
> /var/tmp/portage/mail-client/thunderbird-52.4.0/work/thunderbird-52.4.0 is
> the build directory Thi is automatically deleted when TB has been installed.

Probably off-topic for this bug, but I see about the same when I shutdown my personal build of tb:

WARNING: YOU ARE LEAKING THE WORLD (at least one JSRuntime and everything alive inside it, that is) AT JS_ShutDown TIME.  FIX THIS!
Leaked URLs:
  resource://gre-resources/counterstyles.css
  resource://gre-resources/html.css
  chrome://global/content/minimal-xul.css
  resource://gre-resources/quirk.css
  resource://gre/res/svg.css
  chrome://global/content/xul.css
  chrome://global/skin/scrollbars.css
  resource://gre-resources/number-control.css
  resource://gre-resources/forms.css
  :
  : <-- continues for hundreds (maybe thousands) of lines

This is a apparently a issue know to the tb/moz long-time developers but not a showstopper:
https://bugzilla.mozilla.org/buglist.cgi?order=Importance&list_id=13939948&resolution=---&query_format=advanced&longdesc=LEAKING%20THE%20WORLD&product=MailNews%20Core&product=Thunderbird&longdesc_type=substring
(In reply to gene smith from comment #35)
> WARNING: YOU ARE LEAKING THE WORLD (at least one JSRuntime and everything
> alive inside it, that is) AT JS_ShutDown TIME.  FIX THIS!
Well known issue. Hard to find out what's leaking.
> imap_capability = +SPECIAL-USE
> 
> With your dovecot, it *does* send the SPECIAL-USE capability so it must be
> configured correctly for this, but, as I pointed out above, you need to add
> the "INBOX." in front of each of your special_use mailbox specifications in
> /etc/dovecot/conf.d/15-mailboxes.conf, like this:
> 
> namespace inbox {
> 
>   mailbox INBOX.Drafts {
>     special_use = \Drafts
>   }
>   mailbox INBOX.Junk {
>     special_use = \Junk
>   }
>   mailbox INBOX.Trash {
>     special_use = \Trash
>   }
>   mailbox INBOX.Sent {
>     special_use = \Sent
>   }
>   mailbox INBOX.Archives {
>     special_use = \Archive
>   }
> }
> 
I changed /etc/dovecot/conf.d/15-mailboxes.conf. Does not work on my server. Mailboxes are created my ISPconfig. Will try again after Christmas with the new server.
(In reply to gene smith from comment #34)
> Created attachment 8937922 [details] [diff] [review]
> 1335982-review-changes0.patch
> 
> This prevents an unwanted Trash folder creation on tb restart when the
> wanted trash folder is not at root level, e.g., it is at Inbox/Trash.

The new patch works fine with TB 54.4.0.
(In reply to Elmar Haag from comment #38)
> (In reply to gene smith from comment #34)
> > Created attachment 8937922 [details] [diff] [review]
> > 1335982-review-changes0.patch
> > 
> > This prevents an unwanted Trash folder creation on tb restart when the
> > wanted trash folder is not at root level, e.g., it is at Inbox/Trash.
> 
> The new patch works fine with TB 54.4.0.

Correction:
The new patch works fine with TB 52.4.0. Have not tested the patch with TB 52.5.0.
(In reply to Jorg K (GMT+1, mostly AFK 22-27 Dec., bustage-fix only) from comment #36)
> (In reply to gene smith from comment #35)
> > WARNING: YOU ARE LEAKING THE WORLD (at least one JSRuntime and everything
> > alive inside it, that is) AT JS_ShutDown TIME.  FIX THIS!
> Well known issue. Hard to find out what's leaking.

I worked a very long time ago for a software company producing mission critical software for the mining and health industries. They always had problems with memory leaks, etc. which caused significant damage to machinery and put lives at risk, until the managemnet prohibited the use of Java, C++. Only to use standard ANSI C and only to create monolithic executables that do not reference any libraries.
Comment on attachment 8937922 [details] [diff] [review]
1335982-review-changes0.patch

Thanks for the analysis, but we try to avoid doing home-grown parsing. I'll attach a better patch in the next comment.
Attachment #8937922 - Attachment is obsolete: true
Attachment #8937922 - Flags: review?(jorgk)
Attached patch 1335982-trash-parsing.patch (v1) (obsolete) — Splinter Review
OK, you can review this. This compiles but I haven't tested it since I don't have any "irregular" trash folders at hand?

Take a look at
https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIURI.idl
We basically want the path after the first slash, disregarding the two slashes after the IMAP scheme.
Attachment #8939026 - Flags: review?(gds)
//MsgUnescapeString(trashPath, nsINetUtil::ESCAPE_URL_PATH, unescapedName);
// trashPath starts with /  -- obtain substring at offset 1
MsgUnescapeString(Substring(trashPath, 1), nsINetUtil::ESCAPE_URL_PATH, unescapedName);

With the above change it behaves the same as the "home-grown" way. However, doing some more tests to verify (and understand) things. Seeing something that doesn't make sense that is the same using either way...
Hmm, I haven't tried it at all, but I'm surprised that GetPathQueryRef() would return a leading slash. But hey, the documentation in nsIURI.idl says:
     * The path, typically including at least a leading '/' (but may also be
     * empty, depending on the protocol).
Thanks, I added skipping the slash.
Attachment #8939026 - Attachment is obsolete: true
Attachment #8939026 - Flags: review?(gds)
Attachment #8939150 - Flags: review?(gds)
Comment on attachment 8939150 [details] [diff] [review]
1335982-trash-parsing.patch (v1b)

Review of attachment 8939150 [details] [diff] [review]:
-----------------------------------------------------------------

The patch now works fine and, as is, should resolve the reporter's bug.

However, I did notice bad behavior that should be in another bug report. If another folder under INBOX is selected as the "trash" folder it doesn't appear with the trash icon even after the account is collapsed and expanded or if tb is restarted. Also, in this state with no trash icon on any folder, deleted emails seem to be lost. If the original Trash folder is re-selected as the destination, the icon still does not return to it and deleted mails seem lost. The only way I found to cause the icon to be properly set on the newly designated trash folder (and for deletes to it to work) is to go into server settings and select either "just mark it as deleted" or "remove it immediately" and click OK. Then go back to server settings and select "Move it to this folder" and click OK. Then collapse and expand the account. Then the desired folder has the trash icon and deletes go to it. I found a fix for this in nsImapProtocol.cpp but I will address this in a separate new bug.
Attachment #8939150 - Flags: review?(gds) → review+
Here is the bug described in comment 46 that I just entered: Bug 1427507
Assignee: nobody → gds
Status: UNCONFIRMED → ASSIGNED
Component: Account Manager → Networking: IMAP
Ever confirmed: true
Product: Thunderbird → MailNews Core
Version: 52 Branch → 52
Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/bcfa74cb6921
for trash folder use proper URI parsing instead of home-made parsing (analysis by Gene Smith). r=GeneSmith
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Gene, thanks for the analysis. We'll meet again in bug 1427507. What about bug 1345266? Isn't that ready to go?
Target Milestone: --- → Thunderbird 59.0
Attachment #8939150 - Flags: approval-comm-esr52?
Attachment #8939150 - Flags: approval-comm-beta+
Depends on: 1428666
We didn't do well here, this caused bug 1428666.

Also, we didn't fix the comment:
https://hg.mozilla.org/comm-central/rev/bcfa74cb6921#l1.25
Now we're taking the name as the entire path. On my IMAP server I see INBOX/Trash as the trash name when I print it out.
Patch 1335982-trash-parsing.patch (v1b) does not work on my systems with TB 52.4.0 and TB 52.5.0.
I modified the Gene's original patch to work with TB 52.5.0.

--- a/mailnews/imap/src/nsImapIncomingServer.cpp
+++ a/mailnews/imap/src/nsImapIncomingServer.cpp
@@ -1561,21 +1561,22 @@
                 continue;
               }
             }
             else
             {
               // trashName is the leaf name on the folder URI, which will be
               // different from the folder GetName if the trash name is
               // localized.
               nsAutoCString trashURL;
               trashFolder->GetFolderURL(trashURL);
-              int32_t leafPos = trashURL.RFindChar('/');
+              int32_t slashSlashPos = trashURL.FindChar('/', 0) + 2;  // actually,
+              int32_t leafPos = trashURL.FindChar('/', slashSlashPos);
               nsAutoCString unescapedName;
               MsgUnescapeString(Substring(trashURL, leafPos + 1),
                                 nsINetUtil::ESCAPE_URL_PATH, unescapedName);
               nsAutoString nameUnicode;
               if (NS_FAILED(CopyMUTF7toUTF16(unescapedName, nameUnicode)) ||
                   trashName.Equals(nameUnicode))
               {
                 continue;
               }
               if (numFolders == 1)

I also removed the directories created in my test account test@c5ace.com to avoid confusion when testing.
The IMAP account for testing:
server: mail.c5ace.com
login: test@c5ace.com
Password: Thunderbird

Webmail: www.c5ace.com/webmail
login: test@c5ace.com
Password: Thunderbird
You can use Sqirrelmail to delete unwanted folders.

The test account can receive, but not send mail.
Hi Elmar,
Thanks for trying the patch. However, I don't see a difference between my patch and Jorg's patch that you say "doesn't work" for you. I assume you mean that with that patch the Trash folder outside of Inbox is coming back on tb restart? I just tested with both patches and, once I delete the initially created trash outside of Inbox, and assign the inner Trash as trash, it never comes back after at least 3 restarts and/or many collapse/expands, with *both* patches.

However, Jorg above claims the patch is causing another problem. I need to ask him for more details...

Also, the test account is still working and is useful for testing this.
I'm going to give more details in a minute in bug 1428666.

I'm not 100% happy with what we have here:
https://dxr.mozilla.org/comm-central/rev/007155df7eb96eaa992085feb7e086d61d96e577/mailnews/imap/src/nsImapIncomingServer.cpp#1561

The comment says:
// trashName is the leaf name on the folder URI, ...
but then we use GetPathQueryRef(trashPath) and that returns the full path, in the case I've seen INBOX/Trash. Storing that into the preference a few lines down has further unwanted effects.

But since Gene has a whole heap of experience, let's focus on bug 1428666 for now.

At the very least we need to fix the comment here to explain why it's OK to get the path if we want a leaf.

Of course the patch using GetPathQueryRef(trashPath) doesn't compile(!) based on TB 52, since at that version the function was called GetPath(). It was renamed in bug 1386916 in mozilla57. So Elmar, you can use the patch, but rename the function.
Attachment #8939150 - Flags: approval-comm-esr52?
The code we're changing came from bug 1156669: https://hg.mozilla.org/comm-central/rev/358db6b87dc9

-              nsAutoString folderName;
-              if (NS_FAILED(trashFolder->GetName(folderName)) ||
-                  folderName.Equals(trashName))
+              // trashName is the leaf name on the folder URI, which will be
+              // different from the folder GetName if the trash name is
+              // localized.
+              nsAutoCString trashURL;
+              trashFolder->GetFolderURL(trashURL);
+              int32_t leafPos = trashURL.RFindChar('/');
+              nsAutoCString unescapedName;
+              MsgUnescapeString(Substring(trashURL, leafPos + 1),
+                                nsINetUtil::ESCAPE_URL_PATH, unescapedName);
+              nsAutoString nameUnicode;
+              if (NS_FAILED(CopyMUTF7toUTF16(unescapedName, nameUnicode)) ||
+                  trashName.Equals(nameUnicode))

Before we compared trashName to the folder returned from trashFolder->GetName(folderName), afterwards there was some more elaborate processing. Both only stored a leaf name, but Kent's patch documented that. The patch in this bug changes to a path name.

Sadly the preference is not defined anywhere and it's also not documented whether it should contain a full path or just a leaf name. Kent's patch from bug 1156669 claims it's the leaf name, but observed behaviour in the account manager is that the preference is set to a path value. Just open the account settings and select a new trash. BTW, Gene pointed that out, I'm just documenting it here.

In this context we also have bug 1351479 on file. The user picks a trash folder and restarts, and the code we're looking at here resets the path stored in the preference to a leaf name. And next time we visit the panel, the choice of folder is lost.

Kent also added this comment:
https://hg.mozilla.org/comm-central/rev/358db6b87dc9#l1.12
nsresult rv = GetTrashFolderName(trashFolderName);
...
//     trashFolderName is a leaf name. So this will not find INBOX.Trash

He documented that he thought that trashFolderName was a leaf name and noted a deficiency as a consequence. He didn't consider that right after choosing a trash folder, it is in fact a path.

In summary: Landing this patch here would also fix bug 1351479 since we'd remove the code path from the system that restores the preference back to a leaf name.

Let me suggest a patch with more documentation.
This is the same code we landed previously but with a lot of changed comments.

The idea is to establish the fact that the preference trash_folder_name now consistently contains a PATH like it always was before the code here came to clobber it :-(
Attachment #8941524 - Flags: review?(gds)
Comment on attachment 8941524 [details] [diff] [review]
1335982-trash-parsing.patch (v2)

Review of attachment 8941524 [details] [diff] [review]:
-----------------------------------------------------------------

This patch (or the earlier version that works with v52) will fix Elmar's special problems. However to fix the more general problem where personal namespaces exist and the separator delimiter is '.', the patch included in Bug 1428666 is needed too.

::: mailnews/base/prefs/content/am-server.js
@@ -396,5 @@
>  {
>    var trashFolderName = document.getElementById("imap.trashFolderName").getAttribute("value");
>    // if the preference hasn't been set, set it to a sane default
>    if (!trashFolderName) {
> -    trashFolderName = "Trash";

The only way I ever saw this used was if I go into config editor and reset the trash_folder_name and then the <namespace>/Trash folder is created by the missing trash folder creation code I have be dealing with. But your warranty is invalid if you do this. It may also occur if the imap server has no Trash folder when you create the account. I think this is what Elmar is seeing (but we have discussed workarounds for this).

::: mailnews/imap/src/nsImapIncomingServer.cpp
@@ +48,4 @@
>  
>  using namespace mozilla;
>  
> +// Despite its name, the contains a folder path, for example INBOX/Trash.

Typo: the contains --> this contains
Comment on attachment 8941524 [details] [diff] [review]
1335982-trash-parsing.patch (v2)

I take the comment as an r+. I'll s/the/this/ when landing this. Thanks for looking it over.
Attachment #8941524 - Flags: review?(gds) → review+
Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/d8d5f8093401
Store full folder path in pref trash_folder_name and document it everywhere (analysis by Gene Smith). r=GeneSmith
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
Hi Gene,
Just returned from a long trip in the Outback. Modified "1335982-trash-parsing.patch (v2)" to match TB 52.5.2. "1335982-V2-52.5.2-trash-parsing.patch".

Function "uri->GetPathQueryRef(trashPath);" called at line 173 of the modified patch (line 159 of the original patch) does not exist in the TB 52.5.2 source tree and causes causes a make error failure.

TB 52.5.2 is the latest version available with Gentoo.
I modified this patch for TB 52.5. Function "uri->GetPathQueryRef(trashPath);" called at line 173 of the modified patch (line 159 of the original patch) does not exist in the TB 52.5.2 source tree and causes causes a make error.
Jorg said above that if you change the name from GetPathQueryRef to GetPath it should work with TB 52.5.x. If that doesn't work the only choice is to use the last patch I submitted, I think.

From comment above:
> Of course the patch using GetPathQueryRef(trashPath) doesn't compile(!) based on TB 52, since at that version the function was called GetPath(). It was renamed in bug 1386916 in mozilla57. So Elmar, you can use the patch, but rename the function.
Renaming GetPathQueryRef(trashPath) to GetPath(trashPath) works fine for TB 52.5.2.
Attachment #8944225 - Attachment is obsolete: true
Fixed make failure TB 52.5.2 by changing line 173 from uri->GetPathQueryRef(trashPath); to uri->GetPath(trashPath);
Comment on attachment 8939150 [details] [diff] [review]
1335982-trash-parsing.patch (v1b)

Not that GetPathQueryRef(trashPath) needs to be changed to GetPath(trashPath).
Attachment #8939150 - Flags: approval-comm-esr52?
Comment on attachment 8939150 [details] [diff] [review]
1335982-trash-parsing.patch (v1b)

This would need to go with four more bugs and it's not worth it at TB 52.7 when TB 60 ESR is coming out six weeks later.
Attachment #8939150 - Flags: approval-comm-esr52?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: