Closed Bug 115764 Opened 23 years ago Closed 23 years ago

sporadic Trunk crashes in [@ nsWindow::OnDragMotionSignal] w/drag'n'drop


(Core :: DOM: Copy & Paste and Drag & Drop, defect)

Not set





(Reporter: bugzilla, Assigned: pavlov)



(Keywords: crash, regression, topcrash)

Crash Data


(1 file, 2 obsolete files)

i've encountered crashes several times today using 2001.12.17.08 comm linux bits

* dragging a mail message into another folder [3pane window]
* dragging a link from one tabbed browser to another

it doesn't happen *all* the time, alas, but it's been frequent enough (at least
four times today) that it should be filed...

talkback reports look the same:

handle_gdk_event() + 0x17d7f (0x40357d7f) + 0x11773 (0x4038b773) + 0x11d39 (0x4038bd39) + 0x11eec (0x4038beec) + 0x94333 (0x402a6333)
main() + 0x1c507 (0x404d1507)
have you seen this recently, terri?
Keywords: crash, regression
I'm seeing this alot on my 12/17 nightly.  cc'ing pav because timers are on the

talkback shows these crashes starting on the 16th, and still going strong.
I saw this.. It looked like it was due to one of the window's member variables
was null... perhaps mDragMotionContext. The only significant change to timers on
unix is that now timers don't fire as gtk events but isntead as plevents.
jay or janc, have you seen these crashes cropping up more frequently lately?
Talkback data shows there were 7 crashes with 12/16 builds and 25 with 12/17
builds.  There doesn't appear to be any crashes with 12/18 we'll
have to wait and see if this is still crashing with the most recent MozillaTrunk
Adding topcrash keyword and Trunk to summary for tracking since there have been
quite a few crashes in recent builds.
Keywords: topcrash
Summary: sporadic crashes in nsWindow::OnDragMotionSignal() w/drag'n'drop → sporadic Trunk crashes in [@ nsWindow::OnDragMotionSignal] w/drag'n'drop
jay, are the crashes limited to Linux, or are they occurring in other platforms too?
sairuh: this looks like a linux specific crash...talkback doesn't show any
incidents with the "nsWindow::OnDragMotionSignal" stack signature for windows or
mac.  it might be happening on other platforms...but in that case the stack
signature must be different.  

has anyone experienced this crash on those platforms?  if so it would be
interesting to find out what stack signature is being reported for windows and mac.
I'll bet that this is because we're not using gtk timers anymore so the event
ordering is all screwed up.  The timers used to take precedence over native X
and other events in the mainloop.  I'll bet this is happening because the timers
are firing after the event that would have removed it or something.  It might be
worth it to try to move it to a native gtk timer to get the proper event
ordering here.
Keywords: nsbeta1
This is the #1 topcrash for the period 12-20 to 12-23, even though it only
happens on Linux.  Should this really be assigned to blake?
This is pavlov's.  I'll look at it while he's on vacation; I'll probably need
blizzard's help.

Assignee: blakeross → pavlov
Keywords: mozilla0.9.8
Attached patch round 2 - fight! (obsolete) — Splinter Review
This patch returns FALSE from the timer callback, cancelling the timer.
Attachment #62916 - Attachment is obsolete: true
Attached patch patch 3Splinter Review
This patch removes the extra mDragMotionTimer member variable.
Attachment #62918 - Attachment is obsolete: true
No longer blocks: 115520
Oops. I didn't get a midair. I only CC'd myself at 115520. Readding block 115520.
Blocks: 115520
*** Bug 117382 has been marked as a duplicate of this bug. ***
This bug is slightly different from 117382 according to both poster's comments.
 I experience 100% reproducible crashes like bug 117382.  Is this caused by the
same code?
Just for the record, it doesn't matter what object is picked up, text, img, etc,
if it is dropped onto it's self, moz crashes.
david, have you tried this patch?
Incidentally, if bug 117382 is indeed a duplicate of this, you don't need
to drop the selected object on itself.  You can either drop it anywhere in
the window, or drag it out of the window (without dropping).
Easy-to-reproduce test case: 

* go to a folder in an imap server
* select a message
* forward it
* one-by-one, drag additional messages from that folder into the attachments
pane of the compose window of the forwarded msg
* after 2 or 3 drags, this crash will happen
I tried this with and without the patch in this bug and it seems to fix the
crash.  dmose, is that your experience as well?
Comment on attachment 62919 [details] [diff] [review]
patch 3

Attachment #62919 - Flags: review+
Comment on attachment 62919 [details] [diff] [review]
patch 3


(4! FOUR!)
Attachment #62919 - Flags: review+ → superreview+
Patch 3 does appear to fix this for me, yes.
Checked in.  Rock on.
Oh, fixed.
Closed: 23 years ago
Resolution: --- → FIXED
*** Bug 116419 has been marked as a duplicate of this bug. ***
*** Bug 117619 has been marked as a duplicate of this bug. ***
*** Bug 114664 has been marked as a duplicate of this bug. ***
No talkback data with buildIDs after the checkin. VERIFIED.
Crash Signature: [@ nsWindow::OnDragMotionSignal]
You need to log in before you can comment on or make changes to this bug.