DND doesn't work in mail/news on linux

VERIFIED FIXED

Status

()

Core
XUL
P3
major
VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: blizzard, Assigned: blizzard)

Tracking

({pp, relnote})

Trunk
x86
Linux
pp, relnote
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

18 years ago
If you try to drag a message from your inbox to another folder in linux it
doesn't work.  There is drag feedback but the drop event doesn't result in the
move to happen.

Updated

18 years ago
QA Contact: paulmac → elig

Comment 1

18 years ago
This works on Win32 & Mac. adding beta1, pp to keywords. cc phil
Keywords: beta1, pp

Comment 2

18 years ago
As much as we'd love to have it, we can ship beta without this. And this: we're 
very impressed that it works on windows.
Whiteboard: [PDT-]

Comment 3

18 years ago
Due to extant bugs, we have to either disable D&D on Linux, which would require 
new code to be written by Netscape engineers, or we could just let blizzard 
finish this work for beta. PDT- means Netscape does more work but doesn't get 
the feature, PDT+ means we get the feature at blizzard's expense. clearing PDT- 
for reconsideration. cc pinkerton.
Whiteboard: [PDT-]

Comment 4

18 years ago
When this bug is fixed, I'll refer to bug 10870 to make sure drag and drop works
in mail/news on Linux.

Comment 5

18 years ago
Putting on the PDT+ radar for beta1.
Whiteboard: [PDT+]
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED

Updated

18 years ago
Whiteboard: [PDT+] → [PDT+] Blizzard unavailable until 2/28 due to move

Comment 6

18 years ago
Putting to PDT-, will release note for beta1.
Keywords: relnote
Whiteboard: [PDT+] Blizzard unavailable until 2/28 due to move → [PDT-] Blizzard unavailable until 2/28 due to move
(Assignee)

Comment 7

18 years ago
Ok, I've debugged the problem to the point where I need some help from the
mail/news team trying to track it down.  The problem shows up in the
DropOnFolderTree() function in messengerdnd.js:

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

the statement at line 161 is:

var dropOn = treeItem.getAttribute("dd-dropon");

which always returns false.  Where is this attribute set?  Why would it not be
set?  Is it possible that the drop is happening on the wrong folder?  I don't
know much about RDF or the tree view.  I'm hoping the mail/news team can help
out a bit trying to track this down.
that xul atom (see 
http://lxr.mozilla.org/seamonkey/source/layout/xul/content/src/nsXULAtomList.h#131)

gets set by some xul tree code.

http://lxr.mozilla.org/seamonkey/search?string=ddDropOn

sounds like you need to talk to hyatt or pinkerton.
but this works on win32/mac...and it's set only if the data source (not the tree 
view) says that we are allowed to drop on that node.....back to you ;)
(Assignee)

Comment 10

18 years ago
Ok, I'll try to figure out why that target is not being set properly.

Comment 11

18 years ago
*** Bug 30773 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 12

18 years ago
This was in private email, just wanted to add it to the bug...



\layout\xul\content\src\nsXULAtomList.h(131):XUL_ATOM(ddDropOn, "dd-dropon")

/layout/xul/base/src/nsToolbarDragListener.cpp, line 298 --
content->SetAttribute ( kNameSpaceID_None, nsXULAtoms::ddDropOn, onChild
? "true" : "false", PR_FALSE );
/layout/xul/base/src/nsTreeRowGroupFrame.cpp, line 2133 -- else if (
aAttribute == nsXULAtoms::ddDropOn ) {
/layout/xul/base/src/nsTreeItemDragCapturer.cpp, line 236 --
content->SetAttribute ( kNameSpaceID_None, nsXULAtoms::ddDropOn,
onMe ? "true" : "false", PR_TRUE );
/layout/xul/base/src/nsTreeItemDragCapturer.cpp, line 288 --
content->SetAttribute ( kNameSpaceID_None, nsXULAtoms::ddDropOn,
"false", PR_TRUE );
/layout/xul/content/src/nsXULAtomList.h, line 131 -- XUL_ATOM(ddDropOn,
"dd-dropon")

Comment 13

18 years ago
*** Bug 32225 has been marked as a duplicate of this bug. ***

Comment 14

18 years ago
*** Bug 32225 has been marked as a duplicate of this bug. ***

Comment 15

18 years ago
Any progress on this?

Updated

18 years ago
Keywords: beta2

Updated

18 years ago
Blocks: 26609

Comment 16

18 years ago
Please reevaluate, this time for beta2.
Whiteboard: [PDT-] Blizzard unavailable until 2/28 due to move

Comment 17

18 years ago
blizzard?

This bug (together with bug 27790) is the largest usability problem of Mailnews
for me.

Comment 18

18 years ago
chris, we have to have this done ASAP in M16, bumping severity to major.  If 
you can't target M16, please let us know and I'll reassign it, probably to 
pavlov if it is infrastructure work, or to seth or alecf if only app-level work 
remains.
Severity: normal → major
(Assignee)

Comment 19

18 years ago
I'm working on this right now.  I'll let you know how far I get in the next
couple of hours.
(Assignee)

Comment 20

18 years ago
Ok, now I know why this is happening.  Working on a fix.
(Assignee)

Comment 21

18 years ago
Ok, have a fix.  Once my tree finishes rebuilding and I look at it a little
harder I'll try to get a review.
(Assignee)

Comment 22

18 years ago
Created attachment 7570 [details] [diff] [review]
patch
(Assignee)

Comment 23

18 years ago
Patch attached.  The problem was that before gtk sends the drag_drop signal it
will send a drag_leave signal first.  This caused the state managers for the
drag code for the tree to make the tree item an invalid drag target and the drop
would fail.  We don't actually need the drag_leave signal for anything so I just
removed it.
(Assignee)

Comment 24

18 years ago
*** Bug 30803 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 25

18 years ago
syd has reviewed this.  I'll check it in when the tree stops trying to pretend
it's a message from god or something.

Comment 26

18 years ago
worksforme with blizzard's patch modulo bugs.
(Assignee)

Comment 27

18 years ago
What do you mean "modulo bugs?"

Comment 28

18 years ago
When I filed several msgs via D&D and then replied to another msg, I saw the
drag icon move from the folder, where I filed the msgs, to the current mouse
cursor position several times in an interval of maybe 5s. Looked very spooky
(sp?).

I also had severe problems with D&D in the bookmarks manager (bookmarks inserted
at wrong position, although the visual feedback was correct, etc.) and was not
sure, if they will also appear in mailnews.

Comment 29

18 years ago
The composer doesn't have to be open - I also saw it with onyl the reader being
open.

BTW: Thanks trudelle for helping to get the ball rolling and tnx blizzard for
fixing.
(Assignee)

Comment 30

18 years ago
Fix checked in for this bug.  I opened a seperate bug for the "ghost window" for
anyone that cares.  Please see bug #35932 for that.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Assignee)

Comment 31

18 years ago
Please ignore the spam.  Changing address.
Assignee: blizzard → blizzard
Status: RESOLVED → NEW
(Assignee)

Comment 32

18 years ago
bustage from my reassign
Status: NEW → RESOLVED
Last Resolved: 18 years ago18 years ago

Comment 33

18 years ago
Linux (2000-04-17-11 16)
Drap and drop works both in POP and IMAP.
Status: RESOLVED → VERIFIED

Updated

18 years ago
Keywords: nsbeta2
You need to log in before you can comment on or make changes to this bug.