791497 - [Gmail]/Trash is not flagged as specialized folder when using google's recommended settings for Thunderbird("Just mark it as Deleted") or "Remove it immediately", then File/"Empty Trash" does do nothing on any folder including [Gmail]/Trash

Status: RESOLVED WORKSFORME

(Thunderbird :: Folder and Message Lists, defect)

Description

[David Lechner (:dlech)]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0.1
Build ID: 20120905151427

Steps to reproduce:

Background: this is assuming you are following the recommended settings from Google - http://support.google.com/mail/bin/answer.py?hl=en&answer=78892
Key setting (in Server Settings) in question here is: When I delete a message > Mark it as deleted

In recent versions of TB, up to 15, when you changed this setting, TB "remembers" the trash folder that was previously selected. By this, I mean that in the Folder Pane, the [Gmail]/Trash folder has the special trash icon and if you are using Unified view, [Gmail]/Trash is included in the Trash smart folder.


Actual results:

In TB 16, it appears someone has 'fixed' the "When I delete a message" settings so that if "Mark it as deleted" or "Remove immediately" is selected, then the Trash folder is unflagged. The [Gmail]/Trash folder no longer has the special Trash icon and does not appear in the Trash smart folder in the Unified view.


Expected results:

This fix is good in general, but there should be a special case for GMail. GMail automatically moves items to the Trash folder on the server side, so [GMail]/Trash should be flagged as the Trash folder regardless of what the user selects for "When I delete a message"

Comment 1

[WADA:World Anti-bad-Duping Agency]

I could see this bug with following procedure in Tb trunk 2012/7/18 build(Tb17.0a1).
(1) Server Settings, IMAP Delete model :
    "Just mark it as deleted" or "Remove it immediately" (not "Move to trash")
    mail.server.serverX.trash_folder_name :
      any of reset status(no trash_folder_name), existent folder such as TrashX.
    At this stage, [Gmail]/<trash-name> may be used as "trash" folder for Tb.
    (Shown with trash can icon, "Empty Trash" is shown at folder context menu) 
(2) To force first access of [Gmail]/<trash_name> with non "move to trash model",
    change Display Language: of Gmail account via Web Interfce.
    Gmail's trash folder name via IMAP depends on Display Language:
      English(US)        : [Gmail]/Trash
      English(UK)        : [Gmail]/Bin
      日本語(==Japanese) : [Gmail]/&MLQw33ux-　(== [Gmail]/ゴミ箱)
(3) Collapse then Expand Gmail account at Tb's folder pane
(4) Gmail's trash folder is shown with ordinal folder icon,
    and "Empty Trash" is not shown in folder context menu.
    No folder has "trash can icon" nor "Empty Trash" context menu.
    i.e. There is no trash folder for Tb, dispite that Gmail returns in XLIST.
    => This bug is reproduced.
(5) Change IMAP delete model of Tb to "Move to trash"(existent folder, TrashX),
    and save Server Settings change.
    TrashX is shown with trash can icon, but sooner or later while accessing
    Gmail IMAP folder, [Gmail]/<trash_name> is shown with trash can icon and
    "Empty Trash" is added to context menu of [Gmail]/<trash_name>,
    then TrashX is shown with ordinal icon and "Empty Trash" is removed from
    context menu of TrashX.
(6) Once [Gmail]/<trash_name> is usd as Tb's trash folder(has "Empty Trash" in
    folder context menu) by using "Move to trash model", it was kept when trash
    folder name change of "Move to trash model", when reset of trash name
    (reset of mail.server.serverX.trash_folder_name), and when delete model
    change to "Just mark it as deletd" or "Move it immediately".

Phenomenon is confirmed.

For what should be:
Even if Gmail moves mail to Trash foder([Gmail]/Trash via IMAP) by "Delete operation at Web Interface", there is no reason that Tb must have special "trash folder" when Tb won't do "move mail to trash folder by Delete operation".
So, "no trash folder in Tb" is not inproper behaviour even with Gmail IMAP.

Problems are;
- Tb's behaviour is prety inconsistent.
- If "no trash folder in Tb for Gmail IMAP account", it's very confusing for
  user, because POP3 account has always trash folder and Gmail has trash folder.
- Even if "Just mark it as deleted" or "Remove immediately", I think context
  menu of "Empty Trash" is a mandatory feature. So, this bug can be called "loss
  of "Empty Trash" feature. 

Currently usable workaround.
  Use an existent folder as trash folder of "Move to trash model",
  then change to "Just mark it as deleted" or "Remove it immediately".

Comment 2

[David Lechner (:dlech)]

> Currently usable workaround.
>   Use an existent folder as trash folder of "Move to trash model",
>   then change to "Just mark it as deleted" or "Remove it immediately".

What I am seeing is that this workaround only works if you do not touch the trash folder selection. If a user manually selects a trash folder from the list and then changes to "Just mark it as deleted" or "Remove it immediately" the workaround does not work. 

I have been using this workaround for some time. In my initial comment, I thought that the breakage was new in TB 16, but it looks like I just recently figured out how to break the workaround.

So, is it worth writing a patch? If it is, I would also like to look at Bug 533140 since it is in the same area.

Comment 3

[WADA:World Anti-bad-Duping Agency]

(In reply to David Lechner (:dlech) from comment #2)
> > Currently usable workaround.
> >   Use an existent folder as trash folder of "Move to trash model",
> >   then change to "Just mark it as deleted" or "Remove it immediately".
> What I am seeing is that this workaround only works if you do not touch the
> trash folder selection. If a user manually selects a trash folder from the
> list and then changes to "Just mark it as deleted" or "Remove it
> immediately" the workaround does not work. 

"Use" in my comment meant;
  1. change to "Move to trash" model, select an existent folder of the Gmail IMAP
     account, and click "OK" at Server Settings panel.  
  2. access a folder of the Gmail IMAP account with "Work Online" mode,
     or collapse/expand the Gmail account if folder is already accessed.
  3. after [Gmail]/Trash is changed to trash of Tb, change delete model.
If step 2 is bypassed, "XLIST while mode to trash model" is not execute by Tb.
Is your "the workaround does not work" this case?

Comment 4

[David Lechner (:dlech)]

> "Use" in my comment meant;
>   1. change to "Move to trash" model, select an existent folder of the Gmail
> IMAP
>      account, and click "OK" at Server Settings panel.  
>   2. access a folder of the Gmail IMAP account with "Work Online" mode,
>      or collapse/expand the Gmail account if folder is already accessed.
>   3. after [Gmail]/Trash is changed to trash of Tb, change delete model.
> If step 2 is bypassed, "XLIST while mode to trash model" is not execute by
> Tb.
> Is your "the workaround does not work" this case?

The steps above only work for a new account. If I try to repeat these steps more than once, I only get the desired results the first time.

Comment 5

[Kent James (:rkent)]

(In reply to David Lechner (:dlech) from comment #2)
> 
> So, is it worth writing a patch? If it is, I would also like to look at Bug
> 533140 since it is in the same area.

I think this is worth fixing, yes.

Comment 6

[WADA:World Anti-bad-Duping Agency]

This bug can't be observed in Tb 31.3.0.
By Folder Rediscovery, "Trash" flag of other than [Gmail]/Trash is removed, and "Trash" flag of [Gmail]/Trash is always set according to XLIST response, regardless of Trash folder choice at Server Settings and IMAP delete model choice.
("Trash folder choice at Server Settings is ignored" ==  Bug  533140)
=> "Empty Trash" currently always works if Gmail IMAP regardless of IMAP delete model choice,
      because "Empty Trash" is executed for "first folder which has Trash flag in an account".

Comment 7

[WADA:World Anti-bad-Duping Agency]

Closing as WORKSFOME. Please re-open if it's wrong, or problem will occur again by future changes.