Closed
Bug 196012
Opened 21 years ago
Closed 21 years ago
crash while hovering over menu - Trunk M130 [@ nsEventStateManager::DispatchMouseEvent] [@ 0x00000960 | 0x00000780 | 0x00000000]
Categories
(Core :: DOM: Events, defect, P1)
Core
DOM: Events
Tracking
()
VERIFIED
FIXED
People
(Reporter: aha, Assigned: john)
References
Details
(4 keywords)
Crash Data
Attachments
(3 files, 5 obsolete files)
776 bytes,
text/html
|
Details | |
1.38 KB,
patch
|
peterlubczynski-bugs
:
review+
bryner
:
superreview+
asa
:
approval1.4b+
|
Details | Diff | Splinter Review |
12.50 KB,
text/plain
|
Details |
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•21 years ago
|
||
Reporter | ||
Comment 2•21 years ago
|
||
Reporter | ||
Comment 3•21 years ago
|
||
Reporter | ||
Comment 4•21 years ago
|
||
-> Layout
Assignee: asa → other
Component: Browser-General → Layout
QA Contact: asa → ian
Comment 5•21 years ago
|
||
just to make sure someone else also reproduced the crash, I crashed Mozilla 2003030408 on Win2k using the testcase.
Reporter | ||
Comment 6•21 years ago
|
||
It's regression between 2003021908/trunk (not crashing) and 2003022008/trunk build (crashing -> TB17755730K, TB17755715M).
Keywords: regression
Comment 8•21 years ago
|
||
Able to crash it on 20030305(1.3b) mozilla nightly trunk build on Windows XP.
Priority: -- → P1
Comment 9•21 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•21 years ago
|
Flags: blocking1.3?
Assignee | ||
Comment 10•21 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.
Comment 11•21 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•21 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•21 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•21 years ago
|
||
Attachment #116292 -
Attachment is obsolete: true
Attachment #116293 -
Attachment is obsolete: true
Attachment #116294 -
Attachment is obsolete: true
Updated•21 years ago
|
Flags: blocking1.3? → blocking1.3-
Comment 16•21 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]
Comment 18•21 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•21 years ago
|
||
Attachment #116448 -
Attachment is obsolete: true
Updated•21 years ago
|
Flags: blocking1.4b+
Comment 20•21 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•21 years ago
|
||
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•21 years ago
|
Attachment #121608 -
Flags: superreview?(bryner)
Attachment #121608 -
Flags: review?(saari)
Updated•21 years ago
|
Attachment #121608 -
Flags: superreview?(bryner) → superreview+
Comment 22•21 years ago
|
||
Reproduced using FizzillaMach/2003-05-01-08-trunk, crashing in "0x74c" after nsEventStateManager::GenerateMouseEnterExit. Setting Hardware=All.
Hardware: PC → All
Comment 23•21 years ago
|
||
Comment 24•21 years ago
|
||
Ummm... this is blocking1.4b+, but is awaiting review for already 10 days. Maybe...
Assignee | ||
Updated•21 years ago
|
Attachment #121608 -
Flags: review?(saari) → review?(peterl)
Assignee | ||
Updated•21 years ago
|
Attachment #121608 -
Flags: review?(peterl) → review?(peterlubczynski)
Comment 25•21 years ago
|
||
Comment on attachment 121608 [details] [diff] [review] Patch r=peterl
Attachment #121608 -
Flags: review?(peterlubczynski) → review+
Assignee | ||
Updated•21 years ago
|
Attachment #121608 -
Flags: approval1.4b?
Comment 26•21 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•21 years ago
|
||
Fix checked in.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 28•21 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•21 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
Updated•13 years ago
|
Crash Signature: [@ nsEventStateManager::DispatchMouseEvent]
[@ 0x00000960 | 0x00000780 | 0x00000000]
Comment 30•10 years ago
|
||
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 32•10 years ago
|
||
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.
Description
•