194493 - M130B Trunk crash when executing javascript command onmouseover [@ nsEventStateManager::GenerateMouseEnterExit ] [@ nsEventStateManager::DispatchMouseEvent]

Status: RESOLVED FIXED

(Core :: Layout, defect, P1)

Description

[Johannes Koskinen]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030221
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030221

In the page http://www.futurecrew.com/skaven/, the image changing (onmouseover)
code crashes the mozilla. When using IE6.0SP1 the page works fine. I don't know
whether this is a javascript or layout problem.

Reproducible: Always

Steps to Reproduce:
1.Open page http://www.futurecrew.com/skaven/
2.Move mouse cursor on and around the images
3.The mozilla crashes

Actual Results:  
The mozilla crashes instead of changing the picture.

Expected Results:  
Change the picture layout using javascript or don't do anything (if the script
language is not compatible with mozilla one)

Mozilla version 1.3.20030.22105, 
module gklayout.dll versio 1.3.20030.22105, 
Address 0x000c3af5.

Comment 1

[Olivier Cahagne]

confirming using build 2003022202 on Win2k: TB17404345Q.

Comment 2

[Hermann Schwab]

confirming BuildID 2003032108 on Win98: TB17404811W
reminds me at Bug 186132 Crash mouseovering box with CSS - Trunk [@
nsEventStateManager::DispatchMouseEvent] but that one has been fixed Feb 20th.

Comment 3

[Tavis Ormandy]

confirming build 2003022122, Linux x86 talkback: TB17405741M

Comment 4

[Hermann Schwab]

REGRESSION between 2003021908 and 2003022008
faulty, but no crash on build IDs 2003021808 and -1908, crash with -2008 and -2108
Win98SP1, tested with one fresh profile for all tests, and fresh
prorgammdirectory for each unzipped win32-talkback.zip. Can´t give TB-Nbrs,
deleted one directory after sending, and the other one won´t send. URL and
Bug-nbr noted in TB.

faulty: Frontpage-generated. Left Images in the topframe are restored on mouseout,
other images in topframe are replaced by ALT-text on first Mouseover, and with
broken-Image-icon afterwards.

Comment 5

[R.K.Aa.]

Attachment: backtrace from a fresh linux build.

Stack indeed looks like the one in bug 186132.
And the crash occured the third time i moused over an image

Comment 6

[Jacek Piskozub]

Confirming with a fresh CVS trunk build on WindowsME.

Comment 7

[John Keiser (jkeiser)]

This is me.  I have a fix.

Comment 8

[John Keiser (jkeiser)]

Attachment: Patch

This fixes the crash.  The problem is, mLastMouseOverFrame was being set to a
frame that went away during the event.	Even though we deal with this case
entirely *within* DispatchMouseEvent, we don't take care of it in the callers. 
In this patch I made DispatchMouseEvent clear the frame *for* the callers.  I
have checked all callers and this looks like the right thing to do for them.

Comment 9

[John Keiser (jkeiser)]

Attachment: Patch v1.1

I like this patch better, it eliminates a variable.

Please note that while this patch fixes the crash, there is an evangelism on
this site--mouseovers will give you wrong images.  They have an element like <a
... lowsrc="blah"> and they are expecting JavaScript element.lowsrc to give
them the value of that attribute.  That's not how it works.  It may be that IE
supports lowsrc and that's why it works there.

Comment 10

[Olivier Cahagne]

stack from Linux debug build (CVS 10h ago):

#0  0xdddddddd in ?? ()
#1  0x40ebf3ca in nsEventStateManager::GenerateMouseEnterExit (
    this=0x42501348, aPresContext=0x41cb72f8, aEvent=0xbfffece0)
    at nsEventStateManager.cpp:2527
#2  0x40eb7f17 in nsEventStateManager::PreHandleEvent (this=0x42501348,
    aPresContext=0x41cb72f8, aEvent=0xbfffece0, aTargetFrame=0x42b6efb0,
    aStatus=0xbfffe9e4, aView=0x42b49bd0) at nsEventStateManager.cpp:373
#3  0x40d88ebb in PresShell::HandleEventInternal (this=0x425f3ea8,
    aEvent=0xbfffece0, aView=0x42b49bd0, aFlags=1, aStatus=0xbfffe9e4)
    at nsPresShell.cpp:6220
#4  0x40d88b5e in PresShell::HandleEvent (this=0x425f3ea8, aView=0x42b49bd0,
    aEvent=0xbfffece0, aEventStatus=0xbfffe9e4, aForceHandle=0,
    aHandled=@0xbfffe9e8) at nsPresShell.cpp:6150
#5  0x41bd43dd in nsViewManager::HandleEvent (this=0x427afa78,
    aView=0x42b55510, aEvent=0xbfffece0, aCaptured=0) at nsViewManager.cpp:2210
#6  0x41bc9c37 in nsView::HandleEvent (this=0x42b55510, aVM=0x427afa78,
    aEvent=0xbfffece0, aCaptured=0) at nsView.cpp:303
#7  0x41bd3b0f in nsViewManager::DispatchEvent (this=0x427afa78,
    aEvent=0xbfffece0, aStatus=0xbfffebcc) at nsViewManager.cpp:1942
#8  0x41bc9628 in HandleEvent (aEvent=0xbfffece0) at nsView.cpp:80
#9  0x4142d51f in nsWidget::DispatchEvent (this=0x42b57ee0, aEvent=0xbfffece0,
    aStatus=@0xbfffec7c) at nsWidget.cpp:1496
[...]

Comment 11

[saari (gone)]

Comment on attachment 115262 [details] [diff] [review]
Patch v1.1

spiff, r=saari

Comment 12

[Jay Patel [:jay]]

Adding testcase keyword and making topcrash+.  Adding
nsEventStateManager::DispatchMouseEvent to summary as well.  Here is a recent
Talkback incident for future reference:

Incident ID 17444820
Stack Signature 	nsEventStateManager::DispatchMouseEvent 83cbc9d7
Email Address 	
Product ID 	MozillaTrunk
Build ID 	2003022308
Trigger Time 	2003-02-23 15:34:51
Platform 	Win32
Operating System 	Windows 98 4.10 build 67766222
Module 	GKLAYOUT.DLL
URL visited 	http://www.futurecrew.com/skaven/
User Comments 	bugzilla 194493
Trigger Reason 	Access violation
Source File Name 
c:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp
Trigger Line No. 	2447
Stack Trace 	
nsEventStateManager::DispatchMouseEvent
[c:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp, line 2447]
nsEventStateManager::GenerateMouseEnterExit
[c:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp, line 2530]
nsEventStateManager::PreHandleEvent
[c:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp, line 376]
PresShell::HandleEventInternal
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6223]
PresShell::HandleEvent
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6179]
nsViewManager::HandleEvent
[c:/builds/seamonkey/mozilla/view/src/nsViewManager.cpp, line 2208]
nsView::HandleEvent [c:/builds/seamonkey/mozilla/view/src/nsView.cpp, line 309]
nsViewManager::DispatchEvent
[c:/builds/seamonkey/mozilla/view/src/nsViewManager.cpp, line 1944]
HandleEvent [c:/builds/seamonkey/mozilla/view/src/nsView.cpp, line 83]
nsWindow::DispatchEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1117]
nsWindow::DispatchWindowEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1134]
nsWindow::DispatchMouseEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 5374]
ChildWindow::DispatchMouseEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 5629]
nsWindow::ProcessMessage
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 4065]
nsWindow::WindowProc
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1401]
KERNEL32.DLL + 0x363b (0xbff7363b)
KERNEL32.DLL + 0x242e7 (0xbff942e7)
0x00658b66 

Comment 13

[Jay Patel [:jay]]

Is this going to make it into Mozilla 1.3?  The priority or target milestone
still need to be set.

Comment 14

[Asa Dotzler [:asa]]

Comment on attachment 115262 [details] [diff] [review]
Patch v1.1

a=asa (on behalf of drivers) for checkin to 1.3

Comment 15

[John Keiser (jkeiser)]

Fix checked in on 1.3.  Leaving open until tree gets green and fix can be
checked in to trunk.

Comment 16

[John Keiser (jkeiser)]

Checked in on trunk (checked in to 1.3 earlier).  Happy day.