crash while hovering over menu - Trunk M130 [@ nsEventStateManager::DispatchMouseEvent] [@ 0x00000960 | 0x00000780 | 0x00000000]

VERIFIED FIXED

Status

()

Core
DOM: Events
P1
critical
VERIFIED FIXED
16 years ago
4 years ago

People

(Reporter: Adam Hauner, Assigned: John Keiser (jkeiser))

Tracking

(4 keywords)

Trunk
crash, regression, testcase, topcrash+
Points:
---
Bug Flags:
blocking1.3 -
blocking1.4b +

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(3 attachments, 5 obsolete attachments)

(Reporter)

Description

16 years ago
Mozilla 1.3 branch build and also trunk build are crashing on attached testcase.

Repro:
1. open testcase
2. point mouse over first item in main menu
3. after submenu appear, move mouse on it
4. move mouse back to main menu
5. repeat points 2 to 5 until crash

1.3 latest branch build:
TB17749790W
TB17749976G
TB17750023Y

2003030408 trunk build:
TB17749437M
TB17749442M
TB17749455W
TB17749474X
TB17749576Z
TB17749598K
TB17749607H
(Reporter)

Comment 1

16 years ago
Created attachment 116292 [details]
CSS styles for testcase
(Reporter)

Comment 2

16 years ago
Created attachment 116293 [details]
JS for testcase
(Reporter)

Comment 3

16 years ago
Created attachment 116294 [details]
Testcase
(Reporter)

Comment 4

16 years ago
-> Layout
Assignee: asa → other
Component: Browser-General → Layout
QA Contact: asa → ian

Comment 5

16 years ago
just to make sure someone else also reproduced the crash, I crashed Mozilla
2003030408 on Win2k using the testcase.
(Reporter)

Comment 6

16 years ago
It's regression between 2003021908/trunk (not crashing) and 2003022008/trunk
build (crashing -> TB17755730K, TB17755715M).
Keywords: regression

Comment 7

16 years ago
WFM with build 2003021008 under Windows XP SP1.

Comment 8

16 years ago
Able to crash it on 20030305(1.3b) mozilla nightly trunk build on Windows XP.
Priority: -- → P1

Comment 9

16 years ago
Looks a lot like bug 186132 and bug 194493.  I guess this bug is still not
entirely fixed.  

Cc'ing jkeiser@netscape.com

Here is a recent incident submitted:
Incident ID 17755715
Stack Signature 	nsEventStateManager::DispatchMouseEvent f7f363c4
Email Address 	aha@pinknet.cz
Product ID 	MozillaTrunk
Build ID 	2003022008
Trigger Time 	2003-03-05 06:18:58
Platform 	Win32
Operating System 	Windows NT 5.0 build 2195
Module 	gklayout.dll
URL visited 	
User Comments 	
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 6225]
PresShell::HandleEvent
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6181]
nsViewManager::HandleEvent
[c:/builds/seamonkey/mozilla/view/src/nsViewManager.cpp, line 2212]
nsView::HandleEvent [c:/builds/seamonkey/mozilla/view/src/nsView.cpp, line 304]
nsViewManager::DispatchEvent
[c:/builds/seamonkey/mozilla/view/src/nsViewManager.cpp, line 1948]
HandleEvent [c:/builds/seamonkey/mozilla/view/src/nsView.cpp, line 83]
nsWindow::DispatchEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1120]
nsWindow::DispatchWindowEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1137]
nsWindow::DispatchMouseEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 5385]
ChildWindow::DispatchMouseEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 5640]
nsWindow::ProcessMessage
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 4069]
nsWindow::WindowProc
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1404]
USER32.dll + 0x2a244 (0x77e3a244)
USER32.dll + 0x45e5 (0x77e145e5)
USER32.dll + 0xa792 (0x77e1a792)
nsAppShellService::Run
[c:/builds/seamonkey/mozilla/xpfe/appshell/src/nsAppShellService.cpp, line 480]
main1 [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1289]
main [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1639]
WinMain [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1660]
WinMainCRTStartup()
KERNEL32.dll + 0x2847c (0x77ea847c) 
Keywords: topcrash+
Summary: crash while hovering over menu → crash while hovering over menu - Trunk M130 [@ nsEventStateManager::DispatchMouseEvent]
(Reporter)

Updated

16 years ago
Flags: blocking1.3?
(Assignee)

Comment 10

16 years ago
I would like to note that while this shows up as a topcrash due to there being
11 reports, every single one of the reports was generated by aha@pinknet.cz. 
There were no reports from builds between the 26th and the 4th, either due to
difficulty reproducing or the problem not appearing.

Nonetheless, I can reproduce with this testcase and I'm looking at it.  This
appears to be happening due to ClearFrameRefs() not being called at all in this
case ... probably the bit is not being set.

Updated

16 years ago
Blocks: 113492

Comment 11

16 years ago
testcase also crashes linux trunk build 20030305

==> DOM Events
Assignee: other → saari
Component: Layout → DOM Events
Keywords: stackwanted
OS: Windows 2000 → All
QA Contact: ian → desale
(Reporter)

Comment 12

16 years ago
John Keiser: I'm sorry to generate topcrash, but I'm actually designing website
containing this kind of menu. I also tryed different nightbuilds to track begin
of regression.
(Assignee)

Comment 13

16 years ago
Don't get me wrong, I'm happy for many reports, I just wanted to point out that
this may not be as topcrashy as it seems.  Still worth checking in if I can
figure out the cause before 1.3.
(Reporter)

Comment 14

16 years ago
Created attachment 116448 [details]
Simplified testcase
Attachment #116292 - Attachment is obsolete: true
Attachment #116293 - Attachment is obsolete: true
Attachment #116294 - Attachment is obsolete: true

Updated

16 years ago
Flags: blocking1.3? → blocking1.3-
(Assignee)

Comment 15

16 years ago
oh, this is clearly mine
Assignee: saari → jkeiser

Comment 16

16 years ago
Adding [@ 0x00000960 | 0x00000780] to summary since there have been quite a few
crashes like this being reported under those stack signatures as well on the
MozillaTrunk.
Summary: crash while hovering over menu - Trunk M130 [@ nsEventStateManager::DispatchMouseEvent] → crash while hovering over menu - Trunk M130 [@ nsEventStateManager::DispatchMouseEvent] [@ 0x00000960 | 0x00000780]
(Reporter)

Comment 17

16 years ago
Moving to Trunk as M1.3 released.
Version: Other Branch → Trunk

Comment 18

16 years ago
Since we already have a reproducible testcase I'm not going to add anymore
Talkback data to this bug.  Just wanted to note that we are still seeing these
crashes on the MozillaTrunk and that we should get a Target Milestone set for
the bug.
(Reporter)

Comment 19

15 years ago
Created attachment 121411 [details]
More simplified testcase
Attachment #116448 - Attachment is obsolete: true

Updated

15 years ago
Flags: blocking1.4b+

Comment 20

15 years ago
Adding 0x00000000 to summary since Adam just crashed under that stack signature
as well.
Summary: crash while hovering over menu - Trunk M130 [@ nsEventStateManager::DispatchMouseEvent] [@ 0x00000960 | 0x00000780] → crash while hovering over menu - Trunk M130 [@ nsEventStateManager::DispatchMouseEvent] [@ 0x00000960 | 0x00000780 | 0x00000000]
(Assignee)

Comment 21

15 years ago
Created attachment 121608 [details] [diff] [review]
Patch

Oops, lost track of this.  This fixes the problem: the frame may change during
the DispatchMouseEvent method, and if it does and we are holding onto an
external reference to it, we need to ensure that the FRAME_EXTERNAL_REFERENCE
bit is set on the new frame.

I begin to wonder if we should not just stop caching targeted frames and
re-determine where they are.  There are too many ClearFrameRef-related crashes
every time we try to change something.
(Assignee)

Updated

15 years ago
Attachment #121608 - Flags: superreview?(bryner)
Attachment #121608 - Flags: review?(saari)
Attachment #121608 - Flags: superreview?(bryner) → superreview+

Comment 22

15 years ago
Reproduced using FizzillaMach/2003-05-01-08-trunk, crashing in "0x74c" after
nsEventStateManager::GenerateMouseEnterExit. Setting Hardware=All.
Hardware: PC → All

Comment 23

15 years ago
Created attachment 122340 [details]
Crash report generated by FizzillaMach/2003-05-01-08-trunk showing crash at 0x74c after nsEventStateManager::GenerateMouseEnterExit

Comment 24

15 years ago
Ummm... this is blocking1.4b+, but is awaiting review for already 10 days.
Maybe...
(Assignee)

Updated

15 years ago
Attachment #121608 - Flags: review?(saari) → review?(peterl)
(Assignee)

Updated

15 years ago
Attachment #121608 - Flags: review?(peterl) → review?(peterlubczynski)

Comment 25

15 years ago
Comment on attachment 121608 [details] [diff] [review]
Patch

r=peterl
Attachment #121608 - Flags: review?(peterlubczynski) → review+
(Assignee)

Updated

15 years ago
Attachment #121608 - Flags: approval1.4b?

Comment 26

15 years ago
Comment on attachment 121608 [details] [diff] [review]
Patch

a=asa (on behalf of drivers) for checkin to 1.4b.
Attachment #121608 - Flags: approval1.4b? → approval1.4b+
(Assignee)

Comment 27

15 years ago
Fix checked in.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
(Reporter)

Comment 28

15 years ago
I just tested all testcases wit 2003050610/trunk/W2K and Mozilla didn't crash.
Could anybody verify this bug on Linux?

Comment 29

15 years ago
Test cases from comment 14 and comment 19 don't crash my Moz 2003050622 on
Mandrake 9.1. Verifying/fixed for Linux.
Status: RESOLVED → VERIFIED
Crash Signature: [@ nsEventStateManager::DispatchMouseEvent] [@ 0x00000960 | 0x00000780 | 0x00000000]
Created attachment 8462313 [details] [diff] [review]
null MediaInputPort::mGraph when removing port from graph

This shouldn't be necessary, if clients do the right things, but provides some
safety, in case they don't.
Not sure if you noticed ... but I think you left a digit out of your bug # when you did bzexport.
Crash Signature: [@ nsEventStateManager::DispatchMouseEvent] [@ 0x00000960 | 0x00000780 | 0x00000000] → [@ nsEventStateManager::DispatchMouseEvent] [@ 0x00000960 | 0x00000780 | 0x00000000]
Flags: needinfo?(karlt)
Comment on attachment 8462313 [details] [diff] [review]
null MediaInputPort::mGraph when removing port from graph

Ah, thanks Kyle.  196012 was the revision, but I've learned that bzexport treats a single argument as a bug number, not a revision.  (I didn't notice it actually succeeded after telling me about the bug number mismatch.)
Attachment #8462313 - Attachment is obsolete: true
Flags: needinfo?(karlt)
You need to log in before you can comment on or make changes to this bug.