|
findTrash: for (let folder of account.folders) { |
|
// in case user set special as IMAP dir |
|
if (folder.type === folderTypeTrash) { |
|
moves[accountId].trash = folder; |
|
break findTrash; |
|
} |
|
// otherwise look in special, folders named like "[Gmail]" and "[Googlemail]" |
|
if (/^\[[^\/]+\]$/.test(folder.name)) { |
|
for (let subFolder of folder.subFolders) { |
|
if (subFolder.type === folderTypeTrash) { |
|
moves[accountId].trash = subFolder; |
|
break findTrash; |
|
} |
|
} |
|
} |
|
} |
This block of code tries to find the destination of the move by looking at which folder has the type
property set to "trash"
.
To my surprise, it seems that in Thunderbird (tested on 102.10.1), the outcome of this search depends on the user setting of "When I delete a message" for the account.
If "When I delete a message" is set to "Just mark it as deleted" or "Remove it immediately", none of the folders have .type === "trash"
. The so-named "Trash" or "Deleted" folders actually won't have a type
property at all; they're "just" plain folders. Consequently, the move will not happen.
Only by setting the "When I delete.." action as "Move it to this folder ..." can a .type === "trash"
folder be identified. In this case, the action is no different from the "Delete" action.
This kinda defeats the purpose of the extension, which is
to move selected messages to the Trash folder regardless of the mail account's When I delete a message setting.
I wonder if this is a new issue caused by Thunderbird API breaking compatibility? If the type
property can only be set to "trash"
this way, by tying the property with the underlying action of deletion, it seems we have to fall back to something else, e.g. user preference?