290598 - Drag attachment to desktop doesn't copy, may crash [@ nsNativeDragTarget::ProcessDrag ]

Status: RESOLVED WORKSFORME

(Core :: Widget: Win32, defect)

Description

[Mike Cowperthwaite]

TB 1.0+0414, Win2K

Reproducible: not yet

I encountered this while trying to reproduce the symptom of bug 290027 with 
TB 1.0+0407.  I tweaked an old test message with an attachment to give the 
attachment a non-ASCII filename, restarted, and attempted to drag the attachment 
to the desktop.  The first time I tried (after the program had been up for a 
while doing various things), TB crashed on dragging the attachment to the 
desktop.  I did not get a Talkback window.

Then I tried, with the same version, restarting, and dragging a different 
attachment, with a plain ASCII name.  I immediately started getting various odd 
behaviors:

# First drag, a progress dialog appeared, empty except for the title ("5% of 
file.ext"); when I dropped the file, the dialog filled in, then immediately 
disappeared, and the file was not copied.

# Second drag: no progress dialog appeared; when I dropped the file, got "Error 
moving file or folder: Cannot move file: Cannot read from the source file or 
disk."

# Third drag: no progress dialog appeared; when I dropped the file, the file 
appeared on the desktop, and I received a Windows "Application Error" showing a 
null pointer reference ("The instruction at <address> referenced memory at 
0x00000000 ...").  Again, I did not get Talkback.

I ran TB 1.0.2, which did not exhibit this behavior.  I exited and restarted the 
0407 build, and got crash behavior again (still no Talkback).


Subsequently, I downloaded 1.0+0414.  I tested the same behavior (for the plain-
ASCII-named attachment); crashed again, and this time Talkback engaged; 
ID = TB5109124X.  I neglected to note whether the file was in fact copied to the 
desktop at this point.

At this point I took a look in the temporary directory (actually, the *parent* 
of the temporary directory -- see bug 252479 / bug 242631).  The file 
corresponding to the second attachment was there, but with a zero-byte filesize. 
I deleted the file, restarted the 0414 build, and dragged the attachment again; 
this time, it worked as expected.

However, the temp directory did not contain a file corresponding to the original 
drag with the tweaked name.

Comment 1

[Adam Hauner]

Incident ID: 5109124
Stack Signature	nsNativeDragTarget::ProcessDrag c255ca11
Product ID	ThunderbirdTrunk
Build ID	2005041408
Trigger Time	2005-04-15 06:36:18.0
Platform	Win32
Operating System	Windows NT 5.0 build 2195
Module	THUNDE~1.EXE + (000f8ff0)
URL visited	
User Comments	Dragging a GIF attachment from (local) folder to desktop
Since Last Crash	786 sec
Total Uptime	786 sec
Trigger Reason	Access violation
Source File, Line No.
e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/widget/src/windows/nsNativeDragTarget.cpp,
line 228

Stack Trace 	
nsNativeDragTarget::ProcessDrag 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/widget/src/windows/nsNativeDragTarget.cpp,
line 228]
nsNativeDragTarget::DragOver 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/widget/src/windows/nsNativeDragTarget.cpp,
line 299]
ole32.dll + 0xc61bc (0x77b161bc)
ole32.dll + 0xc634c (0x77b1634c)
ole32.dll + 0x8c830 (0x77adc830)
ole32.dll + 0x8c3d0 (0x77adc3d0)
nsDragService::StartInvokingDragSession 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/widget/src/windows/nsDragService.cpp,
line 188]
nsDragService::InvokeDragSession 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/widget/src/windows/nsDragService.cpp,
line 149]
XPTC_InvokeByIndex 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp,
line 102]
XPCWrappedNative::CallMethod 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp,
line 2065]
XPC_WN_CallMethod 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1287]
js_Invoke 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 1314]
js_Interpret 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 3589]
js_Invoke 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 1334]
js_InternalInvoke 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 1411]
JS_CallFunctionValue 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/js/src/jsapi.c,
line 3804]
nsJSContext::CallEventHandler 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/dom/src/base/nsJSEnvironment.cpp,
line 1384]
nsJSEventListener::HandleEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/dom/src/events/nsJSEventListener.cpp,
line 184]
nsEventListenerManager::HandleEventSubType 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1545]
nsEventListenerManager::HandleEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1642]
nsXULElement::HandleDOMEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2194]
nsXULElement::HandleDOMEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2213]
nsXULElement::HandleDOMEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2213]
nsXULElement::HandleDOMEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2213]
nsEventStateManager::GenerateDragGesture 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/content/events/src/nsEventStateManager.cpp,
line 1534]
nsEventStateManager::PreHandleEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/content/events/src/nsEventStateManager.cpp,
line 486]
PresShell::HandleEventInternal 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/layout/base/nsPresShell.cpp,
line 6295]
PresShell::HandleEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/layout/base/nsPresShell.cpp,
line 6142]
nsViewManager::HandleEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/view/src/nsViewManager.cpp,
line 2508]
nsViewManager::DispatchEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/view/src/nsViewManager.cpp,
line 2228]
HandleEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/view/src/nsView.cpp,
line 174]
nsWindow::DispatchEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 1179]
nsWindow::DispatchMouseEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 5895]
ChildWindow::DispatchMouseEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 6148]
nsWindow::WindowProc 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 1471]
USER32.dll + 0x2a420 (0x77e3a420)
USER32.dll + 0x4605 (0x77e14605)
USER32.dll + 0xa7ba (0x77e1a7ba)
nsAppStartup::Run 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/toolkit/components/startup/src/nsAppStartup.cpp,
line 145]
main 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/mail/app/nsMailApp.cpp,
line 61]
KERNEL32.DLL + 0x2893d (0x7c59893d)

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Is this a regression, and if so, what's the window?

Comment 3

[Mike Cowperthwaite]

(In reply to comment #2)
> Is this a regression, and if so, what's the window?

I don't know how to reproduce the symptom, so I can't answer that question.  
The difference between when it was consistently crashing and when it stopped 
crashing occurred at the point when I deleted the zero-byte file that was in the 
temp directory with the same name as the attachment.  That tempfile, 
incidentally, had a timestamp indicating it had happened during the testing, but 
I couldn't say exactly when during the test it was created.

Comment 4

[Wayne Mery (:wsmwk)]

Mike, ever see this again?

Comment 5

[Mike Cowperthwaite]

I haven't, but I haven't tried mucking around with repeated drags of attachments for a while either.  But since the referenced bugs, and especially bug 203307, have been addressed for a while, I'm willing to believe this is OK.