For example http://lxr.mozilla.org/seamonkey/source/widget/src/beos/nsDragService.cpp#175 BRect dragRect; dragRect.Set( aX, aY, aWidth, aHeight); - this is wrong. BRect is supposed to be constructed (from left, top, right, bottom), not from (left,top, width, height)

Ok, I cathed place where moving mails to new folder in Mailnews fails: http://lxr.mozilla.org/seamonkey/source/mailnews/base/resources/content/messengerdnd.js#322 Something sets for us, when we start dragging email, dragAction = 3 (copy+move), but that code requires either 2 or 1 (copy XOR move). For folder frags it all works, http://lxr.mozilla.org/seamonkey/source/mailnews/base/resources/content/messengerdnd.js#170 as this only check if action == copy and returns in that case. And as 3 != copy-action, code performs well. So questions is "who" should set that proper action code - and where. I think that with bookmarks we have same problem

Adding to nsWindow::CallMethod() { switch { case:ONDROP currentDragSession->SetDragAction(action) } } using http://lxr.mozilla.org/seamonkey/source/widget/src/mac/nsDragHelperService.cpp#289 as example, solves problem with DnD in Mailnews and in SeaMonkey bookmarks for me. Mozilla almost always proposes in its InvokeDragSession() calls full set of possible actions via bitmask, So we must decide somewhere in our code what to do actually.

nsWindow part of DnD fix. NB. While SetDragAction must be called before DispatchWindowEvent, EndDragSession must be called even after widget release. If you call it before, code stops working, until you use ObjectProxy or call EndDragSession exclusively for external events.

Comment on attachment 228095 [details] [diff] [review] patch r=thesuckiestemail@yahoo.se

Checking in mozilla/widget/src/beos/nsWindow.cpp; /cvsroot/mozilla/widget/src/beos/nsWindow.cpp,v <-- nsWindow.cpp new revision: 1.130; previous revision: 1.129 done

Fixes wrong rect, and I wish to close THIS bug. All other possible imprevents look related not native dragging and should form another bug. r=?

Regarding the TODO: Don't you thing BoundingBox is ok for that?

At the moment bounding box is absolutely ok, as there is no way to put multiple rects in single DragMessage. But this is remainder for future, e.g. if we decide to create BBitmap in every case, instead simple dragger-rect - and thus may draw several rects we get from aRegion onto that transaprent bitmap. Or even we go for full-pledged bitmap, e.g. with dragging text and images, it will help us to recall that maybe there are already defined places where to put those elements. So it is just about future aesthetics.

Comment on attachment 228142 [details] [diff] [review] minimalistic patch r=thesuckiestemail@yahoo.se

Checking in mozilla/widget/src/beos/nsDragService.cpp; /cvsroot/mozilla/widget/src/beos/nsDragService.cpp,v <-- nsDragService.cpp new revision: 1.17; previous revision: 1.16 done

According to bebits talkback, this patch should be backported to branch. Will do that when back at home.

Comment on attachment 228142 [details] [diff] [review] minimalistic patch BeOS only small change in widget - DragServiceBeOS. asking approval for branch

Comment on attachment 228095 [details] [diff] [review] patch Asking approval for branch checkin, BeOS-only patch in pure BeOS folder/file. Fixes half-broken Drag And Drop

Comment on attachment 228095 [details] [diff] [review] patch a=beltzner on behalf of drivers (NPOTB)

Comment on attachment 228142 [details] [diff] [review] minimalistic patch a=beltzner on behalf of drivers (NPOTB)

Checking in mozilla/widget/src/beos/nsDragService.cpp; /cvsroot/mozilla/widget/src/beos/nsDragService.cpp,v <-- nsDragService.cpp new revision: 1.13.28.2; previous revision: 1.13.28.1 done Checking in mozilla/widget/src/beos/nsWindow.cpp; /cvsroot/mozilla/widget/src/beos/nsWindow.cpp,v <-- nsWindow.cpp new revision: 1.91.4.24; previous revision: 1.91.4.23 done