350543 - Add a menu item for Copy/Move to Folder Again

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[Scott MacGregor]

I thought I filed this one already but can't find it. this tip came from Seth and Mail.app.

Add a menu item to the Messages toolbar menu for:

Copy / Move to 'Folder' Again

Where 'Folder' is the name of the Folder you last copied or moved a message into. And we show "Copy" or "Move" based on the last action (copy or move).

This setting is not saved across sessions and is a per window setting.

It should also show up in the thread and message pane context menus. Basically anywhere the Copy and move menu items show up in the UI.

The item is disabled when 0 items are selected or we don't have a last folder used for a copy or move.

I'm not sure what we should show in the menu when the last folder used for copy or move is null...Hmmm.

Comment 1

[Scott MacGregor]

Attachment: work in progress

functional but not complete.

Comment 2

[Scott MacGregor]

Attachment: complete patch

In addition to the features described in my original comment, this patch now does the following:

1) Adds an item to the thread pane context menu
2) Adds an item to the message pane context menu
3) Persists the action (move or copy) and the folder ID across sessions AND across windows.
4) Made Ctrl-T the keyboard short cut for this feature.


Ideas/suggestions for better pref names than:

// resource ID of the target folder used for the last move
pref("mail.folder.move.target.id", "");
// was the last folder move a copy
pref("mail.folder.move.copy", true);

that last one definetly needs to get renamed!

Comment 3

[Scott MacGregor]

Attachment: screen shot

Comment 4

[David :Bienvenu]

Comment on attachment 235978 [details] [diff] [review]
complete patch

Nice.

mail.folder.move.target.id is the uri, right? And we don't really want all those '.'s since they're not indicating hierarchy in the prefs...so something like:

mail.last_msg_movecopy_target_uri

and mail.last_msg_move_or_copy_was_move

+// resource ID of the target folder used for the last move
+pref("mail.folder.move.target.id", "");
+pref("mail.folder.move.copy", true);  // was the last folder move a copy

should be "last move/copy". and

was the last message move/copy a a copy 

(since we're moving messages, not folders)

Comment 5

[Scott MacGregor]

Attachment: patch as checked in

updated patch based on David's review comments that I checked in.

Comment 6

[(not reading, please use [e-mail] instead)]

Cool scott!  I look forward to trying this out in an upcoming nightly.

> 4) Made Ctrl-T the keyboard short cut for this feature.

in apple mail, it is option command t.  (command t brings up the font dialog)

We don't have a font dialog in tbird, but we could make command t switch focus to the font picker in the editing toolbar.

to make a potential transition from Apple Mail easier, what about:

1) using option command t, instead of command t
2) saving command t, and logging a bug about making command t map to switching focus the font menulist

I was going to mention something about saving command t for tabs (as tbird is getting tabs), but "new blank tab" in mail doesn't make much sense.

what do you think?

Comment 7

[Scott MacGregor]

lol. That's a great suggestion. But mostly because Ctrl-T is already used to check the current account for new mail. I forgot about that. So we have a key conflict right now. Making Ctrl-Shift-T would resolve that conflict :).

Comment 8

[Scott MacGregor]

Attachment: [checked in branch and trunk] use ctrl-shift-t

fix the key command to be ctrl-shift-t

Comment 9

[(not reading, please use [e-mail] instead)]

> Making Ctrl-Shift-T would resolve that conflict

wait, isn't that the key for "get all new messages"?

Comment 10

[Scott MacGregor]

zoinks...it sure is...looks like we have to move away from using 't' for this and using another key.

Comment 11

[(not reading, please use [e-mail] instead)]

scott, a couple things I found while trying it out.

1)

+moveToFolderAgain=Move to "%1$S" Again
+moveToFolderAgainAccessKey=i

this is a problem, as I moved a message into a folder named bugzilla, so I got:

Move To "bugz_i_lla" Again

2)

should drag and drop of a message into tickle your new code, so that after I dnd  move (or copy) a message, the menu item is set to do that move (or copy) again?  

Comment 12

[(not reading, please use [e-mail] instead)]

and...

3)  I really like this menu item for plowing through my bugzilla-todo folder to move messages (as I read them) into my bugzilla folder, using ctrl+t (which will be changing, but still!)

Comment 13

[Scott MacGregor]

(In reply to comment #11)
> scott, a couple things I found while trying it out.
> 
> 1)
> 
> +moveToFolderAgain=Move to "%1$S" Again
> +moveToFolderAgainAccessKey=i
> 
> this is a problem, as I moved a message into a folder named bugzilla, so I got:
> 
> Move To "bugz_i_lla" Again

I'll try to fix that.

> 2)
> 
> should drag and drop of a message into tickle your new code, so that after I
> dnd  move (or copy) a message, the menu item is set to do that move (or copy)
> again?  

No I didn't tie it into drag and drop. I think your initial feature request said to only act on the menus and not drag and drop so i kept that behavior from mail.app. 

Comment 14

[(not reading, please use [e-mail] instead)]

> No I didn't tie it into drag and drop. I think your initial feature request
> said to only act on the menus and not drag and drop so i kept that behavior
> from mail.app. 

oops, I was mistaken in my original request.

I just double checked, and Mail.app version 2.1 (752/752.2) ties dnd move (and copy) into this menu as well.

do you want a spin off bug on this RFE?

Comment 15

[u60234]

Attachment: access key fix

The access key for the grayed out item "Move Again", i.e. when you have not yet moved a message, is always "M", regardless of what a localizer has defined in messenger.dtd.

The entity reference in mailWindowOverlay.xul is not working due to missing prefix and suffix, '&' and ';'.

Comment 16

[Scott MacGregor]

(In reply to comment #10)
> zoinks...it sure is...looks like we have to move away from using 't' for this
> and using another key.
> 

Ctrl-Shift-M seems to be available. What about that one Seth? 

Comment 17

[Scott MacGregor]

Attachment: [checked in on branch and trunk] fix various issues

1) Moves to Ctrl-Shift-M
2) Hooks into drag and drop. Setting these two prefs should be harmless in seamonkey.
3) disabling of the menu item happens through the command handler, we shouldn't be doing it when we set the menu item label.
4) fixes the accesskey problem reported by hasse (thanks for the patch!)
5) fixes the accesskey problem with the folder name picking up the access key.

Comment 18

[(not reading, please use [e-mail] instead)]

> Ctrl-Shift-M seems to be available. What about that one Seth? 

I forget, but is command shift m new message on mac (as well as command n, from bug #271315)

Or, would command shift m be "plain text new message"?

on my mac, with a build from 8/16, command shift m does new message

Comment 19

[(not reading, please use [e-mail] instead)]

from bug #271315:

> Only Command+Shift+M does New Compose Window. (Command+M is reserved for
> the OS Minimize-to-Dock command.)

Comment 20

[Mike Cowperthwaite]

It seems that the first time you run the program with this feature, the menu item is enabled (with no folder name) but does nothing; then after the first Copy or Move, the item is *disabled*, altho the shortcut works.

On restart, it behaves as expected (altho I'm not sure how it would behave on restart if the first session didn't do a Copy/Move).


It's a bit unfortunate that the already-cluttered menu has a new item.  The 'Again' feature could have been implemented as a new subitem of the Move/Copy dropdown:
   Move to  >  Bugzilla in WELL
               ________________
               WELL           >
               Toast          >
               Covad          >
               Local Folders  >

And then if no history exists, the item could simply not be displayed at all.
Plus, this would be extensible to multiple 'recent' entries (bug 207070) rather than hardcoding to a single one.

I don't particularly like the phrasing "Move to <Folder> Again" -- it implies that the *selected* message has already been moved (or copied) to the target folder.

Also: xref bug 253964.



(In reply to comment #0)
> I thought I filed this one already but can't find it.

Bug 338147, I presume.

Comment 21

[Mike Cowperthwaite]

*** Bug 338147 has been marked as a duplicate of this bug. ***

Comment 22

[Scott MacGregor]

(In reply to comment #20)
> It seems that the first time you run the program with this feature, the menu
> item is enabled (with no folder name) but does nothing; then after the first
> Copy or Move, the item is *disabled*, altho the shortcut works.
> 

I'm guessing you are using the stand alone message window. This works for me in the 3-pane. I just tried the stand alone window and see this behavior. Good catch!

Comment 23

[Scott MacGregor]

Attachment: [checked in on branch and trunk]add command updating for the stand alone message window

poor stand alone message window....

Comment 24

[Mike Cowperthwaite]

(In reply to comment #22)
> (In reply to comment #20)
> > It seems that the first time you run the program with this feature, the
> > menu item is enabled (with no folder name) but does nothing; then after the
> > first Copy or Move, the item is *disabled*, altho the shortcut works.
> 
> I'm guessing you are using the stand alone message window.
> This works for me in the 3-pane. 

No, I saw this in the 3-pane.

Comment 25

[Scott MacGregor]

(In reply to comment #24)
> (In reply to comment #22)
> > (In reply to comment #20)
> > > It seems that the first time you run the program with this feature, the
> > > menu item is enabled (with no folder name) but does nothing; then after the
> > > first Copy or Move, the item is *disabled*, altho the shortcut works.
> > 
> > I'm guessing you are using the stand alone message window.
> > This works for me in the 3-pane. 
> 
> No, I saw this in the 3-pane.
> 

Hmm, I'm unable to reproduce that. It's working fine here after resetting the prefs. Are you using an 8/31 build that has https://bugzilla.mozilla.org/attachment.cgi?id=236145 ?

Comment 26

[Mike Cowperthwaite]

(In reply to comment #25)
> Hmm, I'm unable to reproduce that. It's working fine here after resetting the
> prefs. Are you using an 8/31 build that has [attachment 236145 [details] [diff] [review]] ?

Yes, since the shortcut key is Ctrl+Shift+M.  But, I can't reproduce the problem any more either.  I exited TB, edited prefs.js, and deleted the pref line for
  mail.last_msg_movecopy_target_uri
There was no pref line for
  mail.last_msg_movecopy_was_move

On restart, it behaved correctly.  I don't know what happened, but I'm quite sure seeing the problem, as it was surprisingly incorrect; I went back and checked several times to be sure I'd identified it correctly, and I was even more surprised that it stopped misbehaving on restart.  It's a fluke.

Comment 27

[Scott MacGregor]

(In reply to comment #26)
> (In reply to comment #25)
> > Hmm, I'm unable to reproduce that. It's working fine here after resetting the
> > prefs. Are you using an 8/31 build that has [attachment 236145 [details] [diff] [review] [edit]] ?
> 
> Yes, since the shortcut key is Ctrl+Shift+M.  But, I can't reproduce the
> problem any more either.  I exited TB, edited prefs.js, and deleted the pref
> line for
>   mail.last_msg_movecopy_target_uri
> There was no pref line for
>   mail.last_msg_movecopy_was_move
> 
> On restart, it behaved correctly.  I don't know what happened, but I'm quite
> sure seeing the problem, as it was surprisingly incorrect; I went back and
> checked several times to be sure I'd identified it correctly, and I was even
> more surprised that it stopped misbehaving on restart.  It's a fluke.
> 

I don't think it's a fluke, as Asa just came to me with the same situation on his machine. Mac OS X 8/31 build. The menu was enabled. Something isn't right.

Comment 28

[u60234]

(In reply to comment #20)
> It seems that the first time you run the program with this feature, the menu
> item is enabled (with no folder name) but does nothing; then after the first
> Copy or Move, the item is *disabled*, altho the shortcut works.

I see this too in a 2006-09-02 trunk build on Win XP. But I only see the this in the thread and message pane context menus, not in the Message menu.

Steps to reproduce:
1. Reset the mail.last_msg_movecopy_target_uri pref.
2. Start TB.
3. Open the context menu for a message in the thread or message pane. The "Move Again" item is not disabled.
4. Open the Message menu, and the "Move Again" item is disabled.
5. Open the context menu again, and the "Move Again" item is now disabled.

Additionally:
6. Move a message.
7. Open the context menu for another message, and the "Move to <folder> Again" item is disabled.
8. Open the Message menu, and the item is enabled.
9. Open the context menu again, and the item is now enabled.