I crashed opening the mail compose window, stack trace below. Digging a little bit, here's what I think is happening. In the event state manager's SetContentState() method, around http://lxr.mozilla.org/mozilla/source/layout/events/src/nsEventStateManager.cpp# 2543 we're calling nsIDocument::ContentStateChanged(), and passing in elements that may not have their mDocument pointer set. Down in the bowels of XBL, nsBindingManager::WalkRules(), we *assume* that each element has its mDocument member set, see http://lxr.mozilla.org/mozilla/source/layout/xbl/src/nsBindingManager.cpp#783 I'm not sure if the right fix is to be more paranoid in XBL, or if it's to make the ESM not notify with elements that aren't in the document. nsBindingManager::WalkRules(nsBindingManager * const 0x022115e4, nsIStyleSet * 0x0344a3d0, int (nsISupports *, void *)* 0x01ad4be3 SheetHasStatefulStyle (nsISupports *, void *), void * 0x0012f43c, nsIContent * 0x0350dc00) line 783 + 10 bytes StyleSetImpl::WalkRuleProcessors(StyleSetImpl * const 0x00000000, int (nsISupports *, void *)* 0x01ad4be3 SheetHasStatefulStyle(nsISupports *, void *), void * 0x00000001, nsIContent * 0x0350dc00) line 2012 StyleSetImpl::HasStateDependentStyle(StyleSetImpl * const 0x00b22e98 {"screen"}, nsIPresContext * 0x035c8208, nsIContent * 0x0350dc00) line 1109 nsCSSFrameConstructor::ContentStatesChanged(nsCSSFrameConstructor * const 0x0283b170, nsIPresContext * 0x00000000, nsIContent * 0x0350dc00, nsIContent * 0x031152d4) line 9776 + 21 bytes StyleSetImpl::ContentStatesChanged(StyleSetImpl * const 0x0344a3d0, nsIPresContext * 0x035c8208, nsIContent * 0x0350dc00, nsIContent * 0x031152d4) line 1183 PresShell::ContentStatesChanged(PresShell * const 0x029c4258, nsIDocument * 0x02c56560, nsIContent * 0x0350dc00, nsIContent * 0x031152d4) line 3596 nsXULDocument::ContentStatesChanged(nsXULDocument * const 0x02c56560, nsIContent * 0x0350dc00, nsIContent * 0x031152d4) line 1604 nsEventStateManager::SetContentState(nsEventStateManager * const 0x0350dc00, nsIContent * 0x031152d4, int 46490976) line 2578 nsEventStateManager::GenerateMouseEnterExit(nsEventStateManager * const 0x00000000, nsIPresContext * 0x035c8208, nsGUIEvent * 0x02b2e3c8) line 1523 nsEventStateManager::PreHandleEvent(nsEventStateManager * const 0x03473f20, nsIPresContext * 0x035c8208, nsEvent * 0x0012fae8, nsIFrame * 0x0369af44, nsEventStatus * 0x0012faa8, nsIView * 0x034710d0) line 306 PresShell::HandleEventInternal(PresShell * const 0x00000000, nsEvent * 0x0012fae8, nsIView * 0x034710d0, nsEventStatus * 0x0012faa8) line 4228 PresShell::HandleEvent(PresShell * const 0x029c4250, nsIView * 0x034710d0, nsGUIEvent * 0x0012fae8, nsEventStatus * 0x0012faa8, int 0, int & 1) line 4166 + 15 bytes nsView::HandleEvent(nsView * const 0x00000000, nsGUIEvent * 0x0012fae8, unsigned int 8, nsEventStatus * 0x0012faa8, int 0, int & 1) line 379 nsView::HandleEvent(nsView * const 0x00000000, nsGUIEvent * 0x034710d0, unsigned int 8, nsEventStatus * 0x0012faa8, int 0, int & 1) line 352 nsView::HandleEvent(nsView * const 0x00000000, nsGUIEvent * 0x0338e098, unsigned int 8, nsEventStatus * 0x0012faa8, int 0, int & 1) line 352 nsView::HandleEvent(nsView * const 0x00000000, nsGUIEvent * 0x0367b588, unsigned int 8, nsEventStatus * 0x0012faa8, int 0, int & 1) line 352 nsView::HandleEvent(nsView * const 0x00000000, nsGUIEvent * 0x0330e6f8, unsigned int 28, nsEventStatus * 0x0012faa8, int 1, int & 1) line 352 nsViewManager2::DispatchEvent(nsViewManager2 * const 0x00001383, nsGUIEvent * 0x0000000d, nsEventStatus * 0x0012faa8) line 1429 HandleEvent(nsGUIEvent * 0x0360bba8) line 68 nsWindow::DispatchEvent(nsWindow * const 0x0367b6e4, nsGUIEvent * 0x0012fae8, nsEventStatus & nsEventStatus_eIgnore) line 614 + 6 bytes nsWindow::DispatchWindowEvent(nsWindow * const 0x00000000, nsGUIEvent * 0x00000000) line 635 nsWindow::DispatchMouseEvent(nsWindow * const 0x00000000, unsigned int 300, nsPoint * 0x05f91002 {x=??? y=???}) line 3813 ChildWindow::DispatchMouseEvent(ChildWindow * const 0x00000000, unsigned int 300, nsPoint * 0x00000000 {x=??? y=???}) line 4020 + 15 bytes nsWindow::ProcessMessage(nsWindow * const 0x00000000, unsigned int 512, unsigned int 0, long 852301, long * 0x0012fcf0) line 2910 nsWindow::WindowProc(HWND__ * 0x003b0114, unsigned int 512, unsigned int 0, long 0) line 883 + 18 bytes USER32! 77e13eb0() USER32! 77e1401a() USER32! 77e192da() nsAppShellService::Run(nsAppShellService * const 0x00aa0fb8) line 408 main1(int 1, char * * 0x00372758, nsISupports * 0x003727a8) line 958 + 9 bytes main(int 1, char * * 0x00372758) line 1139 + 25 bytes WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00400000, char * 0x00133a84, HINSTANCE__ * 0x00400000) line 1157 + 21 bytes MOZILLA! WinMainCRTStartup + 308 bytes KERNEL3

This is mine.

nsbeta3+, but P2 until we know how often this actually happens.

*** Bug 53280 has been marked as a duplicate of this bug. ***

*** Bug 53280 has been marked as a duplicate of this bug. ***

This is joki's. He's doing a notification for :hover on an element that isn't in the document.

Changing Severity to Critical because several of us in the mail group crash daily bringing up the Compose window. Suresh and Suzanne usually crash bringing up the Compose window the 2nd or 3rd time with in the same session (they have NT4 systems). I crash on my Win98 system on the 4th or 5th crash and Jason crashes around the 6th time with win2000. Can this be bumped to a P1 please?

joki, I think you just need to ensure that out of notifyContent[0], oldHover, and newHover, that you don't put one of those elements into the notifyContent array if it doesn't have a document.

PDT agrees P2 since not everyone is hitting this crash. If everyone was crashing bringing up a compose window, it would be P1.

I agree with hyatt's solution. I'll have it ready momementarily.

*** Bug 53660 has been marked as a duplicate of this bug. ***

Adding topcrash keyword since this shows up prominently in talkback data. Also changing PC/Win2000 to All/All since some of the talkback reports are for Linux.

This patch fixes another instance of this stack trace with rods sent me. I still can't reproduce this one myself but I'm trying to get hyatt to verify the fix for the mail part now. If it works then this should go in.

We (suresh, esther, suzanne, ninoschka) are seeing this everyday with builds on 9/20 and 9/21. We're using Seamonkey for our daily use. We crash around the 3rd or 4th compose, reply or forward of a message. The simple case of just opening and closing the compose window crashes less frequently, but daily use of mail is very frustrating with this crash. Please raise the P2 to a P1.

*** Bug 53748 has been marked as a duplicate of this bug. ***

joki, I was pretty consistently crashing while using mail compose this morning. After appyling your patch it has stopped. So it seems to be the right fix. I'll update the bug if I see a crash.

adding [@ nsBindingManager::WalkRules] for topcrash tracking. let me know if you need any info from talkback.

marking nsbeta3++, P1

PDT: upgrading to PDTP1 as intended earlier.

Folks, are we going to check this patch in? This bug is killing me.

Updating QA Contact.

I was gone over the weekend. I'll try to get it in today.

So the patch checks to see if the old or new element which we're were/are hovering over is still in the doc. If it is not we do not involve the node in any :hover checking/updating.

*** Bug 54138 has been marked as a duplicate of this bug. ***

*** Bug 54196 has been marked as a duplicate of this bug. ***

*** Bug 54196 has been marked as a duplicate of this bug. ***

*** Bug 54202 has been marked as a duplicate of this bug. ***

Re-assigning to myself. I'll check in this patch into the branch and trunk today because Tom is away on an DOM face to face meeting today and tomorrow.

*** Bug 54240 has been marked as a duplicate of this bug. ***

Nisheeth, Can you check in joki's fix into the tree today? Looks like both the trees are open now!! Thanks!!

add scott and myself to cc list - want to verify this fixes another site with a similar stack trace.

*** Bug 48371 has been marked as a duplicate of this bug. ***

Checked in joki's patch into the branch.

Please also check it into the truck ASAP.

*** Bug 53969 has been marked as a duplicate of this bug. ***

is this in the trunk yet?

Checked into the trunk. Marking bug fixed.

Seems to me this bug is intermittent-I'll wait for the mail folks to let me know? Or does anyone have any guaranteed steps to reproduce this bug? Waiting for help. Thanks.

Yes, try going to www.ex-mozilla.org and click on the link that allows you to edit entries - yesterday, it would crash in WalkRules; with the fix, it doesn't.

Yes, try going to www.ex-mozilla.org and click on the link that allows you to edit entries - yesterday, it would crash in WalkRules; with the fix, it doesn't.

Mail news qa testing is OK with New Msg now using branch builds 2000-09-27 on win98, mac and linux. We don't crash anymore bringing up compose window many times (at least 15) in one session. This can be verified for New Msg window

*** Bug 54420 has been marked as a duplicate of this bug. ***

I tried to verify that bug 53969 is really fixed. I went to bug 53969 selected print. Printed to an ps file. After the print dialog vanished, I moved the mouse over the textfields ( as pointed by karnaze) and got repeatable the stack trace under Win98. I made the CVS around 17 CET. Adding me to CC.

I also got this stack trace printing two different bug reports. It seems fixed for mail compose but not fixed for all situations. The bug reports actually printed, but the crashes did occur.

Closing this bug because this bug is fixed. If the printing bug is not fixed then it was wrongly marked a duplicate of this one and should be re-opened. I will do that next.

Marking verified based on QA comments above.

*** Bug 54847 has been marked as a duplicate of this bug. ***

*** Bug 53642 has been marked as a duplicate of this bug. ***