5676 - regression: Move menu doesn't show folders

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect, P3)

Description

[scottputterman]

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.

Comment 1

[lchiang]

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

Comment 2

[lchiang]

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.

Comment 3

[Alec Flett]

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.

Comment 4

[leger]

Putting on QA Blocker RADAR.

Comment 5

[scottputterman]

Attachment: attempt at patch for bug fix.

Comment 6

[scottputterman]

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.

Comment 7

[rods (gone)]

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

Comment 8

[saari (gone)]

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

Comment 9

[chris hofmann]

lets give it a go....

Comment 10

[saari (gone)]

Commited

Comment 11

[chris hofmann]

marking fixed

Comment 12

[fenella]

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

Comment 13

[lchiang]

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.

Comment 14

[scottputterman]

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

Comment 15

[Alec Flett]

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

Comment 16

[esther]

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

Comment 17

[fenella]

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.

Comment 18

[lchiang]

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.

Comment 19

[fenella]

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.

Comment 20

[scottputterman]

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.

Comment 21

[lchiang]

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.

Comment 22

[lchiang]

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.

Comment 23

[fenella]

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.

Comment 24

[Alec Flett]

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...

Comment 25

[lchiang]

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.

Comment 26

[esther]

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