Closed Bug 56270 Opened 22 years ago Closed 21 years ago

[d&d]drag & drop always copies when it should sometimes move

Categories

(Core :: DOM: Editor, defect, P2)

x86
Linux
defect

Tracking

()

VERIFIED FIXED
mozilla0.8

People

(Reporter: Brade, Assigned: blizzard)

Details

(Keywords: platform-parity, Whiteboard: relnote-user)

Attachments

(1 file)

From mangelo on irc:

mangelo: in teh 10 oct linux build of m18, when i highlight some text and then 
drag taht text inot a table, the text is merely copied. that is the drag works 
ok, but the original text outside the table still is there when the drag is 
completed. although the tsxt now appears in the table also
Target Milestone: --- → Future
accepting this bug to get it off the bugzilla daemon radar
Status: NEW → ASSIGNED
I see this on my linux build but not on my mac build...  Linux--both branch and 
trunk.

It seems that drag/drop is always copying on linux...  You can reproduce simply 
by typing some text, selecting it, dragging it to another location within the 
same window.  The result is that you get a copy rather than a move.
Keywords: pp, relnoteRTM
Priority: P3 → P2
Summary: dragging text from outside a table into a table copies → [d&d]drag & drop always copies when it should sometimes move
Target Milestone: Future → mozilla0.9
Whiteboard: relnote-user
so what I'm seeing is that the srcdomdoc in the editor (nsHTMLEditor.cpp) is not
equal to the destdomdoc when they are the same Composer window.  srcdomdoc is
null.  I haven't had much luck yet tracking down why
nsBaseDragService::GetSourceDocument has a null mSourceDocument (which is where
srcdomdoc is coming from).
Turns out mSourceDocument is being cleared (set to null) before the drop happens
because nsBaseDragService::EndDragSession() is being called before drag
listeners get a chance to process the drop:

Here's EndDragSession() is getting called on linux:


#0  nsBaseDragService::EndDragSession (this=0x814a2a0)
    at nsBaseDragService.cpp:206
#1  0x407e072d in nsDragService::EndDragSession (this=0x814a2a0)
    at nsDragService.cpp:178
#2  0x407fb07b in nsWindow::OnDragLeaveSignal (this=0x8871ec8, 
    aWidget=0x885cd28, aDragContext=0x844eeb0, aTime=661319784, 
    aData=0x8871ec8) at nsWindow.cpp:3181
#3  0x407fafb2 in nsWindow::DragLeaveSignal (aWidget=0x885cd28, 
    aDragContext=0x844eeb0, aTime=661319784, aData=0x8871ec8)
    at nsWindow.cpp:3158
#4  0x408cfb89 in ?? () from /usr/lib/libgtk-1.2.so.0
#5  0x408fcfdd in ?? () from /usr/lib/libgtk-1.2.so.0
#6  0x408fc422 in ?? () from /usr/lib/libgtk-1.2.so.0
#7  0x408fa899 in ?? () from /usr/lib/libgtk-1.2.so.0
#8  0x408a03a8 in ?? () from /usr/lib/libgtk-1.2.so.0
#9  0x4089f954 in ?? () from /usr/lib/libgtk-1.2.so.0


Here's how the editor's drop listener is getting called, after EndDragSession()
is called:


#0  nsBaseDragService::GetSourceDocument (this=0x814a2a0, 
    aSourceDocument=0xbfffe5fc) at nsBaseDragService.cpp:132
#1  0x421fe2bc in nsTextEditorDragListener::DragDrop (this=0x8b247e0, 
    aMouseEvent=0x86117ec) at nsEditorEventListeners.cpp:718
#2  0x413a7a2f in nsEventListenerManager::HandleEvent (this=0x8b88f98, 
    aPresContext=0x8a7cf20, aEvent=0xbfffefa8, aDOMEvent=0xbfffeb98, 
    aCurrentTarget=0x8926d4c, aFlags=2, aEventStatus=0xbfffee90)
    at nsEventListenerManager.cpp:1526
#3  0x416c625d in nsDocument::HandleDOMEvent (this=0x8926d20, 
    aPresContext=0x8a7cf20, aEvent=0xbfffefa8, aDOMEvent=0xbfffeb98, aFlags=2, 
    aEventStatus=0xbfffee90) at nsDocument.cpp:3032
#4  0x416f18b9 in nsGenericElement::HandleDOMEvent (this=0x8b60d1c, 
    aPresContext=0x8a7cf20, aEvent=0xbfffefa8, aDOMEvent=0xbfffeb98, aFlags=2, 
    aEventStatus=0xbfffee90) at nsGenericElement.cpp:1425
#5  0x414869d9 in nsHTMLHtmlElement::HandleDOMEvent (this=0x8b60d08, 
    aPresContext=0x8a7cf20, aEvent=0xbfffefa8, aDOMEvent=0xbfffeb98, aFlags=2, 
    aEventStatus=0xbfffee90) at nsHTMLHtmlElement.cpp:185
#6  0x416f1879 in nsGenericElement::HandleDOMEvent (this=0x8a1a20c, 
    aPresContext=0x8a7cf20, aEvent=0xbfffefa8, aDOMEvent=0xbfffeb98, aFlags=2, 
    aEventStatus=0xbfffee90) at nsGenericElement.cpp:1418
#7  0x4145b8b5 in nsHTMLBodyElement::HandleDOMEvent (this=0x8a1a1f8, 
    aPresContext=0x8a7cf20, aEvent=0xbfffefa8, aDOMEvent=0xbfffeb98, aFlags=2, 
    aEventStatus=0xbfffee90) at nsHTMLBodyElement.cpp:901
#8  0x416ea9ef in nsGenericDOMDataNode::HandleDOMEvent (this=0x8695e5c, 
    aPresContext=0x8a7cf20, aEvent=0xbfffefa8, aDOMEvent=0xbfffeb98, aFlags=1, 
    aEventStatus=0xbfffee90) at nsGenericDOMDataNode.cpp:692
#9  0x4173139d in nsTextNode::HandleDOMEvent (this=0x8695e48, 
    aPresContext=0x8a7cf20, aEvent=0xbfffefa8, aDOMEvent=0x0, aFlags=1, 
    aEventStatus=0xbfffee90) at nsTextNode.cpp:252
#10 0x4141ade5 in PresShell::HandleEventInternal (this=0x8b987e0, 
    aEvent=0xbfffefa8, aView=0x8b484c0, aFlags=1, aStatus=0xbfffee90)
    at nsPresShell.cpp:4882
#11 0x4141a96a in PresShell::HandleEvent (this=0x8b987e0, aView=0x8b484c0, 
    aEvent=0xbfffefa8, aEventStatus=0xbfffee90, aForceHandle=0, 
    aHandled=@0xbfffee34) at nsPresShell.cpp:4811
#12 0x41dde5db in nsView::HandleEvent (this=0x8b484c0, event=0xbfffefa8, 
    aEventFlags=8, aStatus=0xbfffee90, aForceHandle=0, aHandled=@0xbfffee34)
    at nsView.cpp:366
#13 0x41dde562 in nsView::HandleEvent (this=0x8b47f20, event=0xbfffefa8, 
    aEventFlags=8, aStatus=0xbfffee90, aForceHandle=0, aHandled=@0xbfffee34)
    at nsView.cpp:350
#14 0x41dde562 in nsView::HandleEvent (this=0x8ac2860, event=0xbfffefa8, 
    aEventFlags=28, aStatus=0xbfffee90, aForceHandle=1, aHandled=@0xbfffee34)
    at nsView.cpp:350
#15 0x41df19e5 in nsViewManager2::DispatchEvent (this=0x8986388, 
    aEvent=0xbfffefa8, aStatus=0xbfffee90) at nsViewManager2.cpp:1437
#16 0x41dddc44 in HandleEvent (aEvent=0xbfffefa8) at nsView.cpp:67
#17 0x407ef358 in nsWidget::DispatchEvent (this=0x8ba4590, aEvent=0xbfffefa8, 
    aStatus=@0xbfffef2c) at nsWidget.cpp:1483
#18 0x407eef9c in nsWidget::DispatchWindowEvent (this=0x8ba4590, 
    event=0xbfffefa8) at nsWidget.cpp:1374
#19 0x407ef410 in nsWidget::DispatchMouseEvent (this=0x8ba4590, 
    aEvent=@0xbfffefa8) at nsWidget.cpp:1510
#20 0x407fb33f in nsWindow::OnDragDropSignal (this=0x8871ec8, 
    aWidget=0x885cd28, aDragContext=0x844eeb0, aX=317, aY=111, 
    aTime=661319784, aData=0x8871ec8) at nsWindow.cpp:3278
#21 0x407fb0ce in nsWindow::DragDropSignal (aWidget=0x885cd28, 
    aDragContext=0x844eeb0, aX=317, aY=111, aTime=661319784, aData=0x8871ec8)
    at nsWindow.cpp:3195
#22 0x408cf7f5 in ?? () from /usr/lib/libgtk-1.2.so.0
#23 0x408fcfdd in ?? () from /usr/lib/libgtk-1.2.so.0
#24 0x408fc422 in ?? () from /usr/lib/libgtk-1.2.so.0
#25 0x408fa899 in ?? () from /usr/lib/libgtk-1.2.so.0
#26 0x408a08b8 in ?? () from /usr/lib/libgtk-1.2.so.0
#27 0x408a00d0 in ?? () from /usr/lib/libgtk-1.2.so.0
#28 0x4089f9cf in ?? () from /usr/lib/libgtk-1.2.so.0
#29 0x408ce9ea in ?? () from /usr/lib/libgtk-1.2.so.0
#30 0x407e6bee in handle_gdk_event (event=0x81f00a4, data=0x0)
    at nsGtkEventHandler.cpp:948
#31 0x4097900b in ?? () from /usr/lib/libgdk-1.2.so.0
#32 0x409a3be6 in ?? () from /usr/lib/libglib-1.2.so.0
#33 0x409a41a1 in ?? () from /usr/lib/libglib-1.2.so.0
#34 0x409a4341 in ?? () from /usr/lib/libglib-1.2.so.0
#35 0x408ce209 in ?? () from /usr/lib/libgtk-1.2.so.0
#36 0x407dbc1a in nsAppShell::Run (this=0x80b1ea8) at nsAppShell.cpp:350
#37 0x4075f674 in ?? ()
   from
/export/builds/mozilla.11_26_00.TRUNK/mozilla/dist/bin/components/libnsappshell.so
#38 0x8056205 in main1 (argc=1, argv=0xbffff854, nativeApp=0x0)
    at nsAppRunner.cpp:1015
#39 0x8056b7a in main (argc=1, argv=0xbffff854) at nsAppRunner.cpp:1255
Grr.  This is because of the crappy way that gtk handles its drops.  The problem
is that I get a drag end event before I get the drop event.  There is no
difference between a drag ending and a drag drop that triggers the drag end.
So, when I get a drop event out of thin air I restart the drag.  In doing so I
probably reset the drag event state in the event management code and you don't
get your DOM document.

I might be able to fix this by tracking that variable in the gtk code if I can
get it and set it as part of the drag start.  Does that sound reasonable?

[ assigning to me as per an offline conversation with brade ]
Assignee: brade → blizzard
Status: ASSIGNED → NEW
Oh.  Now that I've looked at the nsIDragSession interface I see that the DOM
Document is already stored there.  This will be a snap to fix.
Any progress on this? I'm being blocked by the inability to retrieve the source
document in a drop listener.
Target Milestone: mozilla0.9 → mozilla0.8
Attached patch patchSplinter Review
OK, this patch should fix the problem by delaying the drag end event until after
the next mainloop iteration.  It means that we will get a drag drop event before
the drag leave and we don't have to restart the drag session.
r=pavlov
sr=alecf
scary, but consistent
Checked in.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
verified with optimized linux mozilla build from 8am today.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.