263348 - Unable to move a Virtual Folder back to its previous locations.

Status: VERIFIED FIXED

(Thunderbird :: General, defect)

Description

[trix supremo]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040914 Firefox/0.10
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040914 Firefox/0.10

A Virtual Folder can be moved into other locations: The Inbox or into another
folder.  But unable to move the Virtual back to its previous location.

Reproducible: Always
Steps to Reproduce:
1.  Create a Virtual Folder
2.  Move(mouse drag) folder into the Inbox.
3.  Now, attempt to move the folder back to its intial location.

Actual Results:  
Move attempt fails although the root(main POP3) folder does highlight giving the
indication that the move should be allowed.

Expected Results:  
If the Virtual Folder should behave like a normal folder, then moving to prior
locations should be allowed.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Could this bug depends on bug 263990?

Comment 2

[David :Bienvenu]

Trix, can you try this with tomorrow's build? I suspect this would be a dup, as
Henrik suggested.

*** This bug has been marked as a duplicate of 263990 ***

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+2]]

This is not a dupe of bug 263990. I tried to move a virtual folder to another
location which works now. This is be done with the above bug. But moving back to
the original folder doesn't work. JS console shows following exception message:

Exception : CopyFolders [Exception... "Component returned failure code:
0x8052ffff [nsIMessenger.CopyFolders]"  nsresult: "0x8052ffff (<unknown>)" 
location: "JS frame :: chrome://messenger/content/messengerdnd.js ::
DropOnFolderTree :: line 338"  data: no]

There are other strange behaviours when moving a virtual folders between
different real folders. After a while you can't move it until you restart TB.
But this should be tested after the above exception gets killed.

Comment 4

[trix supremo]

david the problem is still occuring on todays build 20041015

Comment 5

[David :Bienvenu]

Attachment: proposed fix

calling ::Delete on the source folder will force the summary file closed, which
will allow us to delete it. And restoring the check that we're reloading the
same folder (but use gPrevMsgFolder to account for virtual folders...) will
prevent the xul content build from causing us to reselect the just deleted
folder, recreating the .msf file we just worked so hard to delete.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2]]

verified with build from version 0.8 (20041021)