The move menu in the 3 pane doesn't currently show folders. It needs to be hooked up to the account datasource. This is also needed to test bug #5510.

Would this be an M5 stopper? The user can move messages currently via drag and drop, right?

Actually, the move menu worked in M4 so this would be a regression and should be fixed for M5. I'm going to set the target milestone for now. If you disagree, pls let me know. Thanks.

There's no Drag 'n Drop in the 5.0 product right now. This sounds like a test stopper to me, but may be fixed when I fix #5609.

Putting on QA Blocker RADAR.

I'm reassigning to rods and cc'ing saari I'm pretty sure the bug is in widget\src\windows\nsWindow.cpp::FindMenu. I've attached a diff for what I think is the solution. If you agree or come up with a better fix, could you check it in. If I'm right, I'm not sure why this was working before. Currently aDepth is increased in every recursive call. This means that when the menu is found, aDepth might be incorrect because it's been increased in previous recursive calls down other submenus. I think the correct solution is not to do any incrementing until the menu is found.

I think Chris is better qualified to fixed this at the moment.

The fix looks OK to me. chofmann, may I check this in?

lets give it a go....

Commited

marking fixed

RE: Linux build(1999-05-03-08) and win32 build (1999-05-03-08) move menu still does not show folders. Re-open the bug

clearing resolution. This needs to be fixed in M5 because not being able to move messages is a regression from M4. We have no way to test this functionality.

I'm pretty sure the fix saari checked in is good. Reassigning to alecf who has the necessary changes to mailshell.xul

I just checked in a fix as a part of #5792

Using 1999050408 win32 build on Win95 this is fixed. Waiting for linux and mac to verify too.

RE: Linux build (1999-05-04-08) The Move menu (Message|Move Message) now shows folders but the Move functionality does not work. I also checked it with Esther on her Linux box, the result is the same as mine.

Here's what I'm going to do. (1) If all three platforms show names of folders in the Move menu item, then we'll mark this bug verified. (2) For any move functionality that doesn't work, we'll either open up new bugs or update any existing move bugs.

More findings on the 1999-05-04-08 build If I close apprunner, run apprunner and open messenger again, the message shows it made a copy to the folder, the original copy was not moved.

The problem is that the Delete part of the move and the copy header part of the move are not taking place. The actual copying of the message is happening. It's because GetURI is returning mailbox_message://host//Inbox instead of mailbox_message://host/Inbox on Linux. Unless this is a total QA stopper (and it works on Windows so we can still test Move Message), this probably won't get fixed for M5 since the code has to be rewritten for M6 and any change to M5 will just be temporary. I'll let Alec expand on this.

This is getting frustrating. I just found out that all the release builds dated 5/4 in the morning are M6 builds and not M5 branch builds. So, Esther and others comments earlier today are for the M6 builds. The release builds dated 5/3 in the evening are the M5 builds. This bug (move menu doesn't show folders) still occurs in M5 on Win32 only. Move menu does not show any folders. Linux does not have this problem. Bottom line: For M5 builds on Win32, Move message does not work since there are no folders displayed. If this isn't going to be fixed, then I will just release note it.

http://bugzilla.mozilla.org/show_bug.cgi?id=5792 is tracking the problem of copy vs. move. Let's just leave this bug to track the move menu items as the original description states.

RE: linux build m5 (1999-05-03-17) The result is the same as m6, ie: The Move meun shows folders, but the Move functionality only Copies, not Move. And I have to close Apprunner and reopen it to see the copy occurs.

I say we release note this for M5, like scott said. The amount of temporary work to fix this is really not worth it. I missed the 17:00 builds yesterday with the windows fix, so I think that the post-1999-03-05-17 builds will have my fix. With my fix, windows should work, Linux will copy, but not move. This is what we should release-note. I'll let QA verify this is the case on newer builds of course...

We will release note this for M5 (for Win32 only). I am going to mark this bug verified. I think that with the exception of the M5 Win32 builds, all M5 builds and M6 builds have the folders displayed in the menus. The actual move functionality bugs, if any, will be covered separately.

Using build 1999050423 M5 out of the 1999-05-05-06-M5 directory on Win95 Move works. Note: on Win95 it moves like it should, does not copy like linux and mac. I will update bug 5792 about the functionality working on Win95