Closed Bug 305421 Opened 19 years ago Closed 19 years ago

drag and drop copies mail folder instead of moving it

Categories

(Thunderbird :: Mail Window Front End, defect)

x86
Linux
defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird1.1

People

(Reporter: mkmelin, Assigned: Bienvenu)

References

Details

(Keywords: fixed1.8, regression)

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.
Keywords: regression
this almost has to be the nsMsgDatabase.cpp change I made, though I didn't see this problem when testing that change.
Assignee: mscott → bienvenu
Flags: blocking1.8b4?
my mistake, looks like the drag drop code is passing in false for isMove, i.e., messengerdnd.js
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.
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.
what do you mean, print? I used dump, and for some reason, it pulled out the key and printed that...
Flags: blocking1.8b4? → blocking1.8b4+
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.
Blocks: 303981
Target Milestone: --- → Thunderbird1.1
Depends on: 305288
Yeah, I've verified that the patch for bug 305288 fixes this.
Fixed by checkin for bug 305288.
Status: NEW → RESOLVED
Closed: 19 years ago
Keywords: fixed1.8
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.