1691295 - New folder does not appear in context menu "Move again"

Status: RESOLVED WONTFIX

(Thunderbird :: Folder and Message Lists, enhancement)

Description

[Dan Pernokis]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:85.0) Gecko/20100101 Firefox/85.0

Steps to reproduce:

Right-click on a test message and COPY or MOVE it to some mailbox folder.
Create a new mailbox folder.
Right-click on another test message and attempt to COPY or MOVE it to the new folder.

Actual results:

Usually, if you COPY or MOVE a message to some mailbox folder, the next popup menu has a selection (the AGAIN choice) to do exactly that operation again -- COPY or MOVE some other message to that same folder.
Immediately after a new mailbox folder is created, the AGAIN choice remains set to the most recent COPY or MOVE operation (which precedes the creation of the new folder).

Expected results:

Since I just created a new folder, chances are very good that I will want to COPY or MOVE something to it right away. So the AGAIN choice should offer up the new folder, and the action -- COPY or MOVE -- would be whatever I did most recently.

But if we go this far, then perhaps have two AGAIN choices: One is always COPY to the most recently used or created folder, and the other is always MOVE to the most recently used or created folder. (I often COPY certain messages to a central archive before I MOVE the same messages to their final resting place. It would be useful to have those two AGAIN choices happen independently.)

Comment 2

[Dan Pernokis]

The functionality here is not the same as Bug 1367034. That bug refers to putting a newly-created folder on the MOST-RECENT list (good idea), which then requires the user to search the list for the new folder. But THIS bug intends to insert the folder name directly into the RIGHT-CLICK menu under the MOVE-TO AGAIN or COPY-TO AGAIN selection so the folder is immediately handy (only one line farther down than the MOST-RECENT selectors).

Steps:
(1) Create new folder for some messages (as per 1367034 spec).
(2) New folder appears in the RIGHT-CLICK menu under "MOVE TO <new-folder-name> AGAIN" for immediate access (except I would eliminate "AGAIN" because this is first use).
(3) Maybe user wants to duplicate messages in the new folder instead (perhaps it's only a temporary tracking folder), so also add "COPY TO <new-folder-name>" to the menu as well.
(4) And since we're putting both options (copy and move) into the RIGHT-CLICK menu, this bug further proposes to permanently offer both MOVE-AGAIN and COPY-AGAIN in the right-click menu. (I often interleave COPYing or MOVEing something to a folder, depending on the message. I'm always having to re-select from RECENT rather than simply right-clicking an AGAIN operation.)
(5) Then the heated debate becomes... Do we put the same folder in both COPY-AGAIN and MOVE-AGAIN? Or do we store them independently, so a MOVE does not change COPY-AGAIN's folder, and vice versa? There are merits to both -- I sometimes use both -- so make it a user preference.

Comment 3

[Wayne Mery (:wsmwk)]

Thanks. I see your point about this not being a duplicate. Note, the proper term for the right+click menu is "context menu". (but there is also the message menu)

Given the age of "recent" functionality (15 years?), that we don't have the request until now (or it is rare)

a) IF we did this I don't think this merits the work and maintenance of a preference.

b) But I don't think we should overload/presume intent that creating a new folder implies the next time we move a message it should move to the new folder. The user might not do a "move again" until a day or a week from creating the folder. In short, I think fixing bug 1367034 - something I fully support, and is overdue - should be sufficient.

Recommend not fixing

Comment 4

[Dan Pernokis]

Thanks, Wayne. I realized it's a can of worms with maintenance of an option -- I didn't really want to go down that road.

But I think my underlying presumption is valid -- that a user creating a new folder most likely did so to hold new content starting right now. I can live with simply putting the newly-created folder in the most-recent list, but I really would like to see it as the MOVE-AGAIN option in the Context Menu ("Right-click" as I've referred to it), preferrably without "again".

Comment 5

[Alessandro Castellani [:aleca]]

I agree with Wayne in setting this as WONTFIX.
Reasons are as follow:

Since I just created a new folder, chances are very good that I will want to COPY or MOVE something to it right away.

This is dangerous as we can't assume what the user wants to do.
Users might want to create 20 new folders all at once and then start organizing messages, so we can't assume that the most recently created folder is always the correct target.

So the AGAIN choice should offer up the new folder, and the action -- COPY or MOVE -- would be whatever I did most recently.

This is also wrong.
The AGAIN choice should repeat exactly what the user did last action, without changing the destination based on other factors.

The possibility of accidental data-loss by doing this is too high.

Comment 6

[Dan Pernokis]

Alessandro, with due respect, I think your argument is faulty in both instances.

If a user creates a folder, chances are good they want to do something with it, but maybe not, as you suggest. BUT this is no more dangerous than retaining the most recent folder & action, creating a new folder, and then intending to move/copy to a third. You can never presume anything a user might do, but as I said, chances are GOOD that a folder is created to be used right away. No harm done if it's not used, but it's unlikely the user wants to repeat exactly what was done previously.

Likewise, if a user moves/copies something (to establish most recent), then creates a folder, how is this any more wrong & dangerous for the newly created folder to be most recent than it is for whatever was done previously. If they're busy creating a new folder, they are likely out of copying/moving-to-the-previous-folder repetition and starting on a new batch of copies/moves. And I'll bet it's likely to the new folder!

As for retaining a pair of COPY AGAIN and MOVE AGAIN options, I will grant that this is a wish, but not a frivolous one. It's more frustrating to do some MOVEs and then try to copy something to the same place. It's far more dangerous for the user to misread a single AGAIN choice -- and have something get moved and disappear from current view -- than it is to have both options available all the time.

Furthermore, how's this for dangerous: the user does a series of COPYs, then a MOVE (which changes the AGAIN function and destination), then blindly does more AGAINs while thinking they are going to be more COPYs. A lot of "data loss" there -- and this is the status quo!

We have to presume the user is a little bit knowledgeable about what they're doing. If they're asleep at the switch, none of what either of us says is going to keep them from messing up. I'm just offering up a little convenience that will definitely help some users -- and might actually prevent others from shooting themselves in the foot.

Comment 7

[Alessandro Castellani [:aleca]]

I'm sorry but your arguments don't make sense.
You're listing various scenarios which are edge cases and might happen, but all these scenarios are results of a direct action of the user.

What you're asking is for the app to try to guess what the user wants to do on a message based on previous adjacent actions. That's not easy to implement, and it opens up to so many edge cases it would be a nightmare to maintain.

The assumption that MOVE/COPY message and CREATE a new folder are directly correlated actions and should be aware of each other is wrong.

Comment 8

[Dan Pernokis]

Yeah, I guess. I see your point. OK, let's resolve it as DONTFIX.