Closed
Bug 203202
Opened 21 years ago
Closed 15 years ago
After deleting stickynote, viewing page src crashes browser in XBL->sticknotes example [@ nsGenericElement::HandleDOMEvent]
Categories
(Core :: XBL, defect)
Core
XBL
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: finlay_bugzilla_2003, Assigned: hyatt)
References
()
Details
(Keywords: crash)
Crash Data
Attachments
(1 file)
7.47 KB,
text/plain
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401 Viewing the src of the XBL sticky notes example crashes during a window following the deletion of one of the sticky notes. Reproducible: Always Steps to Reproduce: [below, CRASH means the feedback agent appearing - I think I had it submit at least one crash record] 1. start the browser afresh 2. choose menu option debug->XBL->#5sticky notes 3. remove the "webvan order" note (by pushing its [X] button) 4. choose menu option view->pagesrc 5. wait 15 seconds 6. close src window - CRASH or alternatively: 1. start the browser afresh 2. choose menu option debug->XBL->#5sticky notes 3. remove the "webvan order" note (by pushing its [X] button) 4. wait 15 seconds 4. choose menu option view->pagesrc - CRASH that 15 second (or so) wait is important - zip through the process quickly and you don't get the crash. Equally the deletion of the note is important - I can't get a crash without doing that. It _seems_ (may be my imagination) that if you successfully avoid the crash one time, you can't get it to happen without closing down and restarting mozilla from scratch. Actual Results: in the former case, src is displayed and looks okay, crash on close in the latter case, crash during bringup of src window Expected Results: view src as normal, with no crash I don't think this is a dupe of #87198, as 1) it's a different pattern and 2) I can't reproduce #87198 myself anyway (on a nondebug build, that is)
Reporter | ||
Comment 1•21 years ago
|
||
1. I did indeed submit a feedback agent thing (using my exciting nom-de-guerre finlay_mozilla_2003_f84a22@mcwalter.net) 2. The feedback agent's "show details" (and the corresponding SaveAS) is blank 3. my comment above about succeeding once immunising one from the crash isn't true - hit the window anytime and it happens, 100%.
Comment 2•21 years ago
|
||
Could you provide talkback incident ID?
Severity: normal → critical
Keywords: crash
Comment 3•21 years ago
|
||
I can reliably repro on OS X 2003042208... but it takes clicking back in the sticky notes area... still a very odd combintaion of behaviors. Talkback ID TB24272OG... i'll attach the full crash log... but here's some data to chew on... ********** Date/Time: 2003-04-24 13:10:15 -0400 OS Version: 10.2.5 (Build 6L29) Host: pnhTiObject.local. Command: mozilla-bin PID: 1848 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000 Thread 0 Crashed: #0 0x00000000 in 0x0 #1 0x00f9ef6c in nsGenericElement::HandleDOMEvent(nsIPresContext*, nsEvent*, nsIDOMEvent**, unsigned, nsEventStatus*) #2 0x0101f1c0 in nsHTMLButtonElement::HandleDOMEvent(nsIPresContext*, nsEvent*, nsIDOMEvent**, unsigned, nsEventStatus*) #3 0x00ff12e4 in nsEventStateManager::PreHandleEvent(nsIPresContext*, nsEvent*, nsIFrame*, nsEventStatus*, nsIView*) #4 0x00e83740 in PresShell::HandleEventInternal(nsEvent*, nsIView*, unsigned, nsEventStatus*) #5 0x00e83504 in PresShell::HandleEvent(nsIView*, nsGUIEvent*, nsEventStatus*, int, int&) #6 0x0112fdf0 in nsViewManager::HandleEvent(nsView*, nsGUIEvent*, int) #7 0x0112f35c in nsViewManager::DispatchEvent(nsGUIEvent*, nsEventStatus*) #8 0x01126b28 in HandleEvent(nsGUIEvent*) #9 0x00b6c500 in nsWindow::DispatchEvent(nsGUIEvent*, nsEventStatus&) #10 0x00b6c58c in nsWindow::DispatchWindowEvent(nsGUIEvent&) #11 0x00b51f44 in nsMacEventDispatchHandler::DispatchGuiEvent(nsWindow*, unsigned) #12 0x00b6a68c in nsWindow::SetFocus(int) #13 0x02d861e8 in GlobalWindowImpl::Focus() #14 0x00ff1818 in nsEventStateManager::PreHandleEvent(nsIPresContext*, nsEvent*, nsIFrame*, nsEventStatus*, nsIView*) #15 0x00e83740 in PresShell::HandleEventInternal(nsEvent*, nsIView*, unsigned, nsEventStatus*) #16 0x00e83504 in PresShell::HandleEvent(nsIView*, nsGUIEvent*, nsEventStatus*, int, int&) #17 0x0112fdf0 in nsViewManager::HandleEvent(nsView*, nsGUIEvent*, int) #18 0x0112f35c in nsViewManager::DispatchEvent(nsGUIEvent*, nsEventStatus*) #19 0x01126b28 in HandleEvent(nsGUIEvent*) #20 0x00b6c500 in nsWindow::DispatchEvent(nsGUIEvent*, nsEventStatus&) #21 0x00b6c58c in nsWindow::DispatchWindowEvent(nsGUIEvent&) #22 0x00b51f44 in nsMacEventDispatchHandler::DispatchGuiEvent(nsWindow*, unsigned) #23 0x00b52154 in nsMacEventDispatchHandler::SetActivated(nsWindow*) #24 0x00b537b0 in nsMacEventHandler::HandleActivateEvent(EventRecord&) #25 0x00b52600 in nsMacEventHandler::HandleOSEvent(EventRecord&) #26 0x00b5a6b4 in nsMacWindow::DispatchEvent(void*, int*) #27 0x00b56488 in nsMacMessagePump::DispatchOSEventToRaptor(EventRecord&, OpaqueWindowPtr*) #28 0x00b56384 in nsMacMessagePump::DoActivate(EventRecord&) #29 0x00b556a0 in nsMacMessagePump::DispatchEvent(int, EventRecord*) #30 0x00b55480 in nsMacMessagePump::DoMessagePump() #31 0x00b4922c in nsAppShell::Run() #32 0x000053c8 in main1(int, char**, nsISupports*) #33 0x00005924 in main #34 0x0000224c in _start #35 0x000020cc in start
OS: Windows XP → All
Hardware: PC → All
Comment 4•21 years ago
|
||
(gdb) where #0 0x087dddc9 in ?? () #1 0x40fc59ea in nsGenericElement::GetBindingParent (this=0x84b50c0, aContent=0xbfffdd2c) at /home/bzbarsky/mozilla/xlib/mozilla/content/base/src/nsGenericElement.cpp:2302 #2 0x40fc4c6d in nsGenericElement::HandleDOMEvent (this=0x84b50c0, aPresContext=0x87a4620, aEvent=0xbfffdfa4, aDOMEvent=0xbfffdc88, aFlags=7, aEventStatus=0xbfffdec0) at /home/bzbarsky/mozilla/xlib/mozilla/content/base/src/nsGenericElement.cpp:1804 #3 0x4104c2d6 in nsHTMLButtonElement::HandleDOMEvent (this=0x84b50c0, aPresContext=0x87a4620, aEvent=0xbfffdfa4, aDOMEvent=0x0, aFlags=1, aEventStatus=0xbfffdec0) at /home/bzbarsky/mozilla/xlib/mozilla/content/html/content/src/nsHTMLButtonElement.cpp:481 #4 0x41027720 in nsEventStateManager::SendFocusBlur (this=0x8672738, aPresContext=0x87a4620, aContent=0x84b50c0, aEnsureWindowHasFocus=1) at /home/bzbarsky/mozilla/xlib/mozilla/content/events/src/nsEventStateManager.cpp:4294 #5 0x4102637f in nsEventStateManager::SetContentState (this=0x8672738, aContent=0x84b50c0, aState=2) at /home/bzbarsky/mozilla/xlib/mozilla/content/events/src/nsEventStateManager.cpp:3983 #6 0x4104bdf2 in nsHTMLButtonElement::SetFocus (this=0x84b50c0, aPresContext=0x87a4620) at /home/bzbarsky/mozilla/xlib/mozilla/content/html/content/src/nsHTMLButtonElement.cpp:333 #7 0x4101cb32 in nsEventStateManager::PreHandleEvent (this=0x8463f78, aPresContext=0x82b7fe0, aEvent=0xbfffe950, aTargetFrame=0x855fb3c, aStatus=0xbfffe72c, aView=0x82b8ca0) at /home/bzbarsky/mozilla/xlib/mozilla/content/events/src/nsEventStateManager.cpp:700 #8 0x40e7f2bc in PresShell::HandleEventInternal (this=0x82b9060, aEvent=0xbfffe950, aView=0x82b8ca0, aFlags=1, aStatus=0xbfffe72c) at /home/bzbarsky/mozilla/xlib/mozilla/layout/html/base/src/nsPresShell.cpp:6370 #9 0x40e7edc2 in PresShell::HandleEvent (this=0x82b9060, aView=0x82b8ca0, aEvent=0xbfffe950, aEventStatus=0xbfffe72c, aForceHandle=1, aHandled=@0xbfffe730) at /home/bzbarsky/mozilla/xlib/mozilla/layout/html/base/src/nsPresShell.cpp:6293 #10 0x41174cbf in nsViewManager::HandleEvent (this=0x82b84d0, aView=0x82b8ca0, aEvent=0xbfffe950, aCaptured=0) at /home/bzbarsky/mozilla/xlib/mozilla/view/src/nsViewManager.cpp:2251 #11 0x4116ad41 in nsView::HandleEvent (this=0x82b8ca0, aVM=0x82b84d0, aEvent=0xbfffe950, aCaptured=0) at /home/bzbarsky/mozilla/xlib/mozilla/view/src/nsView.cpp:308 #12 0x411746eb in nsViewManager::DispatchEvent (this=0x82b84d0, aEvent=0xbfffe950, aStatus=0xbfffe884) at /home/bzbarsky/mozilla/xlib/mozilla/view/src/nsViewManager.cpp:2029 #13 0x4116a7c2 in HandleEvent (aEvent=0xbfffe950) at /home/bzbarsky/mozilla/xlib/mozilla/view/src/nsView.cpp:80 Looks like the focus event crashes.... (gdb) frame 1 #1 0x40fc59ea in nsGenericElement::GetBindingParent (this=0x84b50c0, aContent=0xbfffdd2c) at /home/bzbarsky/mozilla/xlib/mozilla/content/base/src/nsGenericElement.cpp:2302 2302 NS_IF_ADDREF(*aContent); (gdb) list 2297 nsDOMSlots *slots = GetExistingDOMSlots(); 2298 2299 if (slots) { 2300 *aContent = slots->mBindingParent; 2301 2302 NS_IF_ADDREF(*aContent); 2303 } else { 2304 *aContent = nsnull; 2305 } 2306 (gdb) p *slots->mBindingParent $7 = {<nsISupports> = {_vptr. = 0x9}, <No data fields>} So it looks like someone forgot to clear the binding parent on kids of the binding as the binding got torn down... In fact, I see no code anywhere to clear the binding parent at binding teardown! This could be a problem if one of the kids is kept alive by the ESM as the currently focused content or something....
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 5•21 years ago
|
||
Comment 6•21 years ago
|
||
Yeah, definitely not cool. We can have the bound element die while the anon content nodes continue to hold bogus pointers to it.... SetAnonymousContent should clear the binding parent pointers if it can (ie if the XBL binding is only ever attached to one content node). If the binding parent pointers need to live past the point when mContent changes, something else needs to happen....
Summary: After deleting stickynote, viewing page src crashes browser in XBL->sticknotes example → After deleting stickynote, viewing page src crashes browser in XBL->sticknotes example [@ nsGenericElement::HandleDOMEvent]
Comment 7•21 years ago
|
||
I just stumbled across this exact same crash on OpenVMS. I'd created a sticky note and then deleted it, had brought up a "view source" window, and then clicked on the (partially occluded) browser window.
Comment 8•21 years ago
|
||
maybe i'm not waiting as long as i did in the past, but can't seem to repro this now with 2003080803-os x trunk anyone else care to take a stab?
Reporter | ||
Comment 9•21 years ago
|
||
I can still get it, but perhaps the timings have changed a bit. I got it twice with less than a minute's effort each time this morning. I did this just as before - deleting notes, waiting 15 secs (perhaps 20) and viewing the source. New talkback entries are TB22602323H and TB22602402H I'm using a very recent (yesterday) win32 x86 nightly: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030808 So, at least for this platform, the bug appears unchanged. (sorry!)
Comment 10•21 years ago
|
||
*** Bug 216492 has been marked as a duplicate of this bug. ***
Comment 11•20 years ago
|
||
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 Slackware-current Could NOT reproduce this crash.
Updated•15 years ago
|
QA Contact: ian → xbl
Comment 12•15 years ago
|
||
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20091221 Firefox/3.7a1pre Doesn't crash for me.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
Updated•13 years ago
|
Crash Signature: [@ nsGenericElement::HandleDOMEvent]
You need to log in
before you can comment on or make changes to this bug.
Description
•