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 Desktop
Packages, which is subscribed to thunderbird in Ubuntu.
https://bugs.launchpad.net/bugs/885525
Title:
Deleting a Gmail Message Always Sends Item to [Gmail]/Trash
Status in Mozilla Thunderbird Mail and News:
Confirmed
Status in “thunderbird” package in Ubuntu:
New
Bug description:
Thunderbird 7.0.1, Ubuntu 11.10
Gmail accounts do not obey the setting in Account Settings -->
[Account] --> Server Settings --> When I delete a message
I changed this to move the message to Gmail's "All Mail" folder,
attempting to imitate the Gmail web interface's "Archive" option.
However, regardless of setting, the item always moved to Trash. This
persisted after restart of the client. The settings save, but have no
effect.
Caveat: This was tested on two Google Apps for Domains accounts,
though I suspect this behavior will happen with gmail.com accounts as
well.
To manage notifications about this bug go to:
https://bugs.launchpad.net/thunderbird/+bug/885525/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
