1367034 - New folder created is missing on the recent folder list. Need to set MRMTime when creating folder

Status: NEW

(Thunderbird :: Mail Window Front End, enhancement)

Description

[David]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20170517122419

Steps to reproduce:

This is a small thing I had when I used Outlook/Outlook Express and I really miss on Thunderbird.

When you create a new folder under Outlook Express and afterward you select a message(s) and right click to move it to that folder, Outlook Express automatically moves the message(s) into the last folder created, on Thunderbird this feature is missing although I believe the folder should be listed on top of the "Recent" folders.


Actual results:

The new folder created is missing under the "Recent" folders.


Expected results:

I will try to describe what I need and how I used easily achieve this using Outlook Express:

1. I receive an order from a client, it includes several emails, such as order notification, payment notification and confirmation email.

2. I create a new folder named "order-001", and then I select the associated messages above.

3. I right click, select "Move To", the "order-001" folder appears on top as the default folder to move the messages to, I confirm and the messages are moved into that folder.

4. I receive a new order from a different client, again it includes several emails, I create a new folder named "order-002", move the messages to it as described above and so on.

Comment 1

[Wayne Mery (:wsmwk)]

Yeah, the design spec apparently didn't include this. I don't know if it was deemed undesireable, or just was omitted.

Comment 2

[David]

Thank you Wayne, is this something you can add please?

Comment 3

[David]

Any chance you guys can add this please? I don't mind paying for it.

Comment 4

[Wayne Mery (:wsmwk)]

Sorry, I am not a programmer.  Unfortunately, we don't see positive effects from bounties.

Comment 5

[David]

Thank you Wayne, is it possible to assign this to a programmer?

Comment 7

[Kenneth Porter]

Another implementation would be to add "new folder" to the "move to" and "copy to" menus so one can quickly create the new folder without jumping to a completely different menu and then returning to the message context menu.

Comment 8

[Wayne Mery (:wsmwk)]

Mihai, with the success of bug 546722, possible to continue your skills here?

Comment 9

[Mihai]

Sure, I'll take a look and get back to you in a day or two.

Comment 10

[Mihai]

BTW, it might be that the new folders don't yet have a value for MRMTime (the most recently modified timestamp), and thus the menu building ignores them:

              // Find 15 (_MAXRECENT) of most recently modified ones.
              specialFolders = this.getMostRecentFolders(specialFolders,
                                                         this._MAXRECENT,
                                                         "MRMTime");

Comment 11

[Mihai]

So yes, I confirm that the new folders don't yet have "MRMTime" & "MRUTime" values. But so do other folders, depending on how one has historically used them, so checking these two fields for "empty" won't do here. Thinking of other ways...

Comment 12

[Mihai]

Wouldn't it actually make sense to initialize the "MRMTime" & "MRUTime" values to the current time when the folder is created, so that this issue will be indirectly addressed?

As an analogy, this would somewhat be similar to how POSIX defines the three file timestamps handling. And probably as a consequence, GNU C does this: "When a file is created, all three time stamps for that file are set to the current time."

Jorg, who decides if this is acceptable?

Comment 13

[Jorg K (CEST = GMT+2)]

Usually you just submit a patch to fix a bug or implement a feature and then the reviewer decides. This looks reasonable, so I think your patch would be accepted. Let's ask Aceman, he's recently worked in this area.

Comment 14

[Mihai]

Thanks Jorg.

Comment 15

[:aceman]

(In reply to Mihai from comment #12)

Wouldn't it actually make sense to initialize the "MRMTime" & "MRUTime" values to the current time when the folder is created, so that this issue will be indirectly addressed?

The MRUTime and MRMTime seems to be documented here:
https://searchfox.org/comm-central/source/mailnews/base/public/msgCore.h#44

Currently the MRMTime is only changed when a message is copied/moved to a folder (see SetMRMTime() and UpdateTimestamps()).
But initializing it at folder creation time seems reasonable. Users not wanting new folders in the Recent list probably won't be affected much, there will not be a flood of new folders pushing the useful folders out of the Recent list.

Comment 16

[:aceman]

(In reply to Jorg K (GMT+1) from comment #13)

Usually you just submit a patch to fix a bug or implement a feature and then the reviewer decides. This looks reasonable, so I think your patch would be accepted. Let's ask Aceman, he's recently worked in this area.

Of course it is better to ask before submitting a complicated patch and having it shot down :)

Comment 17

[Mihai]

Agreed on all counts, thanks. I'll look into it then.

Comment 18

[Mihai]

I have briefly looked in the past at where the various folder properties are set - in a number of locations actually -, but couldn't yet identify where to best check for the presence of the "MRMTime" & "MRUTime" properties, to initialize them.

So, to anyone willing to take over, please go ahead.

Comment 19

[Jorg K (CEST = GMT+2)]

Aceman, since you've worked on recent folders in bug 949135.

Comment 20

[:aceman]

Yes, actually bug 949135 has shown that the MRUTime of a newly created folder is somewhere in year 2000, but not zero.
Yes, for the Recent submenu in folder picker we need MRMTime, but we could set both.

Comment 21

[Wayne Mery (:wsmwk)]

Mihai, does that give you enough information to proceed?

Comment 22

[Mihai]

(In reply to Wayne Mery (:wsmwk) from comment #21)

Mihai, does that give you enough information to proceed?

No, as it doesn't hint where MRUTime is set, to set MRMTime as well.
Aceman, do you happen to know? It's probably just a one-liner.

Comment 23

[[e-mail]]

The 'Recent' list of folders to move/copy to should contain the folder that has been made the moment before, because the user most likely wants to use the last created folder right away (why else would the user have created a folder?).
I gather the just created folder is an even better candidate for the 'most recently used folder list' then a folder which has been used to put a message in!

Comment 26

[Boomerang_Aide]

(In reply to Mihai from comment #22)

(In reply to Wayne Mery (:wsmwk) from comment #21)

Mihai, does that give you enough information to proceed?

No, as it doesn't hint where MRUTime is set, to set MRMTime as well.
Aceman, do you happen to know? It's probably just a one-liner.

I recently saw how an old archive would ensure the folders it contains would not get ignored during decompression, by making them contain dummy files to be deleted by the user.
If setting those parameters that seem to stall everything is hard to do manually, would it be possible to create a dummy message, move it to the folder, then delete it, allowing older systems to take care of the details?

Comment 27

[Wayne Mery (:wsmwk)]

One or both of these searches should help you

• https://searchfox.org/comm-central/search?q=MRUTime&path=&case=false&regexp=false
• https://searchfox.org/comm-central/search?q=recentfolders&path=&case=false&regexp=false

Comment 28

[NextTherapist]

Wow, this thread is rather old, and I also miss this function. Which folder could be more "recent" than the newest one? I created it because I want to use it, not just for fun.

Comment 29

[David]

Yep, guys please add this function as it's really needed..

Comment 30

[:aceman]

It is because MRMTime that is used to choose folders into the recent list is defined as "Most recently moved to" not "most recently modified":
https://searchfox.org/comm-central/rev/bfefc713c577d1b7db4e06f16bd687ccb7875ea7/mailnews/base/public/msgCore.h#44
But maybe it shouldn't hurt if we add recently created folders to it.

Comment 32

[Hartmut Welpmann [:welpy-cw]]

Attachment: Bug 1367034 - Set MRMTime for manually created or renamed folders. r=#thunderbird-reviewers

Comment 33

[Ben Campbell]

Stepping back a little and ignoring implementation: what should appear on the recent-folder list?
- Folders created by the user
- Folder which have had messages copied/moved into them (by the user, not by filters?)
- Other?

Comment 34

[Wayne Mery (:wsmwk)]

IIRC folders to be excluded:

1. noselect folders
2. folders set as Favorites
3. targets of TB commands like Trash, Spam, Archive
4. targets of automation, eg filters (unless a user has done a manual action)

Everything else where a user has created a folder or done a manual move or copy should be fair game. I can't think of others.

Comment 35

[Dan Pernokis]

Under my Thunderbirds (v91 and v115), FAVORITE folders do show under RECENT if I COPY'd or MOVE'd to them by hand. I wouldn't want that to change, as one may select a FAV folder this time for several repeated operations and would expect it to be there just like any other folder.

I also suggested long ago that a newly-created folder should also appear under RECENT, since I just created it (perhaps in an obscure path) usually with the immediate intention of using it. I stand by that suggestion (as per Comment 33).

Comment 36

[Ben Campbell]

(In reply to Wayne Mery (:wsmwk) from comment #34)

IIRC folders to be excluded:

But if the user had manually moved a message to one of those folders, that should then appear in the Recent list, right?

Dan's comment #35 all sounds pretty intuitive and sensible stuff to me.
Does it boil down to:
"any user-initiated operation that targets a folder should result in that folder being added to the Recent list"
?

Comment 37

[Wayne Mery (:wsmwk)]

Let me first say that my #1 and #4 items can be ignored. My listing them is just confusing.

As for #2 and #3 ...

(In reply to Ben Campbell from comment #36)

(In reply to Wayne Mery (:wsmwk) from comment #34)

IIRC folders to be excluded:

But if the user had manually moved a message to one of those folders, that should then appear in the Recent list, right?

Dan's comment #35 all sounds pretty intuitive and sensible stuff to me.
Does it boil down to:
"any user-initiated operation that targets a folder should result in that folder being added to the Recent list"
?

No, Trash, Junk and Archive, which are likely used many times a day by every user, and which trivially have messages moved to those folders at the stroke of a single key (delete, J and A) should never be listed in Recent. Putting these in Recent will needlessly pollute the list by bumping off other "frequently used" folders. And that is how it works today, you don't see these folders in Recent. (But they do show up in Favorites list if you have marked them as such - I think that's fine)

As for Favorites, I see that current behavior is a Favorites folder does appear in both lists, as Dan mentions. But IMO that is unnecessary and not something I would have expected. I think it is a mistake. If such a folder can be in the Recent list then why offer a Favorites list at all?

Put another way, wouldn't we prefer to offer to the user a total of 40 unique folder names between Favorites and Recent, rather than have Thunderbird force less than 40 because a fav folder can be in both lists?

Comment 38

[Ben Campbell]

We're probably getting too far into the front end side for me to be commenting now, but I will anyway :-)

To me it sounds like the rules are complicated enough that it should be the front end code which manages a "Recent" list - explicitly adding folders when something significant occurs.
This sounds more manageable than the current situation of trying to bend an ill-defined back-end property (MTMtime) to magically produce the list you'd expect. Especially given that the back end doesn't treat explicitly-user-created folders differently (and I don't think it should).

And if the back end doesn't provide the facilities required to do that, then it should, dammit :-)
I just filed Bug 1892531 to cover the createSubFolder() not telling you which folder was actually created issue.

Comment 39

[Hartmut Welpmann [:welpy-cw]]

So let's postpone this until the back-end has caught up.