305421 - drag and drop copies mail folder instead of moving it

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[Magnus Melin [:mkmelin]]

Since 20050820 1.8 branch builds, drag and drop of mail folders copies the
folder instead of moving it. 

To reproduce: drag a folder into another folder. The dragged folder is now
duplicated. The 20050819 build moves the folder as expected. This seems to occur
both for POP and IMAP folders.

Comment 1

[David :Bienvenu]

this almost has to be the nsMsgDatabase.cpp change I made, though I didn't see
this problem when testing that change.

Comment 2

[David :Bienvenu]

my mistake, looks like the drag drop code is passing in false for isMove, i.e.,
messengerdnd.js

Comment 3

[David :Bienvenu]

http://lxr.mozilla.org/mozilla/source/mailnews/base/resources/content/messengerdnd.js#337

Here's the js line that calls into nsMessenger::CopyFolders

isMove is false, even though the source server and targetServer appear to be the
same server. The messengerdnd code has not changed in several months. When I
dump their values, I get:

sourceServer, targetServer[nsIMsgIncomingServer: server11] [nsIMsgIncomingServer
: server11]

It seems as if something is going wrong in js or xpconnect - as unlikely as that
seems because if something so simple was broken, lots more stuff wouldn't work.

Comment 4

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

If you print them both in a debug build, what do you get?

Do you need to QI them both to the same interface?  Wrapper identity has been a
troublesome thing for us in calendar land, but I'm not sure what would have
changed in the window described by the reporter.

Comment 5

[David :Bienvenu]

what do you mean, print? I used dump, and for some reason, it pulled out the key
and printed that...

Comment 6

[Scott MacGregor]

This looks like fall out from Bug #303981. The two server objects are indeed the
same server, but they are wrapped in two different scopes. Hence the comparison
check fails. 

See Bug #305288 which demonstrates an identical symptom in the options dialog on
Mac OS X where a similar comparison between two xpc natvie wrapped objects is
also failing.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Yeah, I've verified that the patch for bug 305288 fixes this.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Fixed by checkin for bug 305288.