1332488 - Please don't exclude junk and trash from move/copy to recent list

Status: RESOLVED WONTFIX

(MailNews Core :: Backend, enhancement)

Description

[Jakob Bohm]

Currently Tb excludes the junk and trash special folders from the list of recent move/copy targets that populates the "Copy To" and "Move To" menus (both right click and Message main menu).

This seems to be a leftover from an earlier workaround for the bug where automatic message actions would pollute that MRU list with the folders they modified, most commonly the junk/trash folders.  Since that bug has apparently been long since fixed, the exclusion no longer makes sense and just gets in the way.

If the previous paragraph is the correct root cause assumption, and the code is still as in the patch that fixed #370324 then the most likely fix is probably simply changing the code in nsMsgDBFolder::UpdateTimestamps() to not check the junk/trash flags and instead move the MRU update inside the "AllowUndo" (or its more exact successor) conditional.  Note that the URL goes to the mentioned old patch that apparently closed #370324 and moved (but not introduced) the check for junk/trash special from two other places to UpdateTimestamps().

Steps to reproduce:

1. Manually move a message to the junk IMAP special folder
2. Manually move a different message to some other IMAP (non-special) folder
3. Right click on a third message intending to move it to the junk IMAP special folder
4. On the right click menu, navigate to "Move To -> Recent" looking for the recently targeted junk IMAP special folder.

Actual result:

At step 4, the junk IMAP special folder is not on the recent list, forcing a slow manual navigation in order to move the third message there.

Expected result:

The junk IMAP special folder should have been in the recent list, since it was the second-most-recently used manual move/copy target (from step 1 of the reproduction).

P.S.

Observed using the shipping 45.6.0 regular build on Windows 8.1, running against various IMAP accounts.

Comment 1

[Wayne Mery (:wsmwk)]

(Please use syntax of bug xxx so the get linked, for example bug 370324)

Indeed, they are intentionally excluded. IIRC, your request would hurt users that don't want to see those folders in Recent, and they would when a message is junked or deleted by a mechanism other than drag and drop. (not just filters)

Comment 2

[Jakob Bohm]

Point is that when *not* allowing Tb to automatically move/delete suspected spam messages, manually moving messages to the junk mailbox is a very common user action, where users are hurt by the current behavior of omitting the junk folder from the MRU list.

Another point is that the extra condition "if (AllowUndo)" added in the referenced patch from 2011 is supposed (according to comments in #370324 and in the patch itself) to already exclude cases where a message is moved, junked, deleted etc. by any of the automated mechanisms.  However the phrasing "proxy for" in that patch hints at this being a potentially imperfect condition for determining if this is an explicit move or copy operation by the user, rather than an implicit one occurring as part of something else (such as the user "deleting" a message).  Finding an even more precise condition to filter out move/copy operations not explicitly done by the user requires more knowledge of Tb internals that I have.

Also note that Drag and Drop to one of the special folders is not the only user action that *should* add something to that MRU list or update its recentness in the list.  The most important other such action would be to use either of the menu items mentioned in Comment #0 to explicitly move/copy a message there.

P.S.

The component and branch that you moved this bug to were not available for selection in the Bugzilla web interface available to me as an outside user, not even as searchable locations in Advanced bug search.  I thus presumed that "45 branch" was the only way to indicate that a bug was in the shipping 45.x.x release and that "Mail Window Front End" was the current component for that code.

Comment 3

[Wayne Mery (:wsmwk)]

I think this is too much of an edge case. And complicated to code if implemented to continue the status quo for users who haven't tweak settings according to comment 2.

Comment 4

[Jakob Bohm]

Please note that as explained in comment #0, this was a simple request to remove no longer useful code that existed only as a bad workaround for a long since fixed bug. It was not supposed to require complex coding of any kind!

Blindly closing long standing bugs you don't understand is really bad behavior!

Comment 5

[Jakob Bohm]

Followup, I see that the original bad exclusion code was in fact :wsmwk 's own idea back in the bug log for Bug 370324, that bug history is a cabinet of coding horrors, where only one of the outside participants knows how to correctly and efficiently implement a basic MRU list, while various Mozillians insisted on an inefficient algorithm that scans all existing folders instead of just the short list being updated and shown.