836631 - Change spec of mail.server.serverN.trash_folder_name to msgFolder.URI from folder name string based on msgFolder.prettiestName, as done in Copies&Folders and Junk Settings

Status: RESOLVED FIXED

(Thunderbird :: Account Manager, defect)

Description

[WADA:World Anti-bad-Duping Agency]

This is spin-off of bug 491424 comment #18.
 
Change spec of mail.server.serverN.trash_folder_name to msgFolder.URL from folder name string based on msgFolder.prettiestName, as done in Copies&Folders and Junk Settings, in order to resolve some busg.

[Background]
> (A) Bug 480393 Localized versions of Thunderbird choose wrong trash folder on IMAP server.
>     (Trash selection UI is inconsistent with localized folder display name & namespace)
Cause of Bug 480393 :
  mail.server.serverN.trash_folder_name requests non-localized trash name,
  but trash selection UI sets localized trash name in trash_folder_name    
> (B) Bug 491424 Problems changing Trash -> Deleted Items
>     (mismatch between namespace usage and trash_folder_name set by trash folder selection UI) 
Cause of Bug 480393 :
  mail.server.serverN.trash_folder_name requests Mbox name without
  Default_personalNamespace when personalNamespace is used,
  but trash selection UI sets Mbox name which starts with personalNamespace
  unless the personalNamespace part is hidden by serverDirectory.

(A) is resolved by simply using string in msgFolder.URI, where localized special folder name won't appear, in trash selection UI logic.
However, if we tries to resolve (B) by trash folder selection UI side change only, we have to add excess/useless code for removing Default_personalName part from Mbox name which is set in mail.server.serverN.trash_folder_name.

This bug is proposal of new trash folder selection at Server Settings what is similar to(or nearly same as) folder selection in Copies&Folders and Junk Setings, in order to avoid adding excess/useless code to trash selection UI logic.

(Step-1) In Tb (nn).(mm).(a)
  Disable trash folder selection UI,
    if localized Tb whose trash!="Trash" : for bug 480393
    if personalNamespace is used         : for bug 491424
  By this change, both bugs automatically disappears,
  because responsibility of trash_folder_name setting is transferred to user.
  "No trash selection UI" is same as Tb 2, but I believe gain by "No trash
  selection UI" is far greater than loss by bug 480393 and bug 491424.
  (loss==ZERO, except that some users can't see the UI what is evil for him.)

(Step-2) In Tb (nn).(mm).(b) where a <= b
  Enhance logic what uses mail.server.serverN.trash_folder_name.

  If trash_folder_name starts with protocol, use this as trash folder URL.
     trash_folder_name = imap://username@hostname/ABC/DEF/Trash
     Same as Copies&Folders/Junk Settings
  Else if trash_folder_name is valid string for foldr name,
  do as currently done and use it as folder name.
     trash_folder_name = ABC/Trash
     Same as current
  Tb can work well with both style of trash_folder_name.

(Step-3) In Tb (nn).(mm).(c) where a <= b < c
  Change spec of mail.server.serverN.trash_folder_name to folder.URI.
  All of (i) trash folder selction UI logic who sets trashFolderName,
  (ii) logic what is invoked upon trashFolderName change,
  (iii) logic what uses mail.server.serverN.trash_folder_name,
  should be changed, according to spec chane of trash_folder_name.

  No migration code is perhaps needed, because old trash_folder_name is
  normally read and used by Step-2, and new folder.URI is saved in
  trash_folder_name by Step-3.

(Step-4) In Tb (nn).(mm).(d) where a <= b < c <= d
  If possible, add option of "Use trash in XLIST" like one in Server Settings,
  in order to support bug 533140, and change logic of DiscoveryDone()
  for bug 533140. 
  This is also a solution of Bug 800035(original Bug 800035 comment #0).

Comment 1

[Wayne Mery (:wsmwk)]

would be cool to get traction on this. 

I suspect this is under-reported. And, iirc this can affect undo capability, so the effects are greater than just bad trash behavior

Comment 2

[Jorg K (CEST = GMT+2)]

Fixed by bug 1430168.