After fix of Bug 798663(landed on Tb 17.0.2), "Gmail IMAA or not" is
detected by X-GM-EXT-1 capability response, and is saved in
kGmailImapCapability bit of Capability flags, and is used as indicator
of "Gmail IMAP", ad is propaated to s_gmail of prefs.js etc.
As for "forcing [Gmail]/Trash as trash folder", it look done by
nsImapIncomingServer::DiscoveryDone() (see bug 829185 comment #11).
Logic of DiscoveryDone() is very simple;
- If Gmail IMAP, force "trash in XLIST reponse" as trash, and clear SpecialUse
flag
- If not Gmail IMAP account, respect mail.server.serverN.trash_folder_name.
One of biggest reasons of "forcing [Gmail]/<trash-in-XLIST>" was localized
<trash-in-XLIST> by Gmail. Because Gmail/Gmail IMAP changes actual Mbox name to
localized name when Display Languge: is changed, and the Display Language:
change can be done by user any time, it's very hard to process following
variants.
Trash in en-US Tb, Trash in localized Tb,
[Gmail]/Trash in en-US Tb, [Gmail]/Trash in localized Tb,
localized-Trash in en-US Tb, localized-Trash in localized Tb,
localized-[Gmail]/Trash in en-US Tb, localized-[Gmail]/Trash in localized Tb
Simplest & certain way is "always use trash in X-LIST".
So, "forcing trash in X-LIST" is still mandatory feature.
But, "prohibiting other than trash in X-LIST as trash of Tb" is never
proper action of an mailer who supports IMAP.
So, "forcing trash in X-LIST if Gmail IMAP" should be optional, although
"forcing trash in X-LIST if Gmail IMAP" should be default.
A possible and simple circumvention of this bug is as follows, altouh it can't
be final, absolutely correct, sufficient solution.
new prefs : mail.server.serverN.force_Gmail_Trash_if_is_gmail(deault=true)
DiscoveryDone() :
If Gmail IMAP && mail.server.serverN.force_Gmail_Trash_if_is_gmail_true
Force trash in X-LIST, clear Trash flag of all other folders,
as currently Tb does
Else If Gmail IMAP
Respect mail.server.serverN.trash_folder_name,
and clear Trash flag of all other folders
Else (non Gmail IMAP)
Do as currently Tb does
However, as I wrote in bug 829185 comment #14, some issues was found in
incomingServer.isGMailServer access and incomingServer.trashFolderName
access from JavaScript. These may produce new problems if
mail.server.serverN.trash_folder_name setting will be used when
is_gmail/isGMailServer is true.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/885525
Title:
Deleting a Gmail Message Always Sends Item to [Gmail]/Trash
To manage notifications about this bug go to:
https://bugs.launchpad.net/thunderbird/+bug/885525/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
