Closed
Bug 53219
Opened 24 years ago
Closed 24 years ago
crash opening mail compose [@ nsBindingManager::WalkRules]
Categories
(Core :: DOM: UI Events & Focus Handling, defect, P1)
Core
DOM: UI Events & Focus Handling
Tracking
()
VERIFIED
FIXED
M18
People
(Reporter: waterson, Assigned: nisheeth_mozilla)
References
Details
(Keywords: crash, topcrash, Whiteboard: [nsbeta3++][PDTP1][ETA - 9/26])
Crash Data
Attachments
(3 files)
1.27 KB,
patch
|
Details | Diff | Splinter Review | |
1001 bytes,
patch
|
Details | Diff | Splinter Review | |
4.56 KB,
text/plain
|
Details |
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
Reporter | ||
Updated•24 years ago
|
Comment 2•24 years ago
|
||
nsbeta3+, but P2 until we know how often this actually happens.
Priority: P3 → P2
Whiteboard: [nsbeta3+]
Target Milestone: --- → M18
Comment 5•24 years ago
|
||
This is joki's. He's doing a notification for :hover on an element that isn't
in the document.
Assignee: hyatt → joki
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?
Severity: normal → critical
Comment 7•24 years ago
|
||
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.
Comment 8•24 years ago
|
||
PDT agrees P2 since not everyone is hitting this crash. If everyone was crashing
bringing up a compose window, it would be P1.
Whiteboard: [nsbeta3+] → [nsbeta3+][PDTP2]
Comment 9•24 years ago
|
||
I agree with hyatt's solution. I'll have it ready momementarily.
Status: NEW → ASSIGNED
Comment 10•24 years ago
|
||
*** 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.
Comment 12•24 years ago
|
||
Comment 13•24 years ago
|
||
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.
Comment 14•24 years ago
|
||
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.
Comment 15•24 years ago
|
||
*** Bug 53748 has been marked as a duplicate of this bug. ***
Comment 16•24 years ago
|
||
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.
Comment 17•24 years ago
|
||
adding [@ nsBindingManager::WalkRules] for topcrash tracking. let me know if
you need any info from talkback.
Summary: crash opening mail compose → crash opening mail compose [@ nsBindingManager::WalkRules]
Comment 18•24 years ago
|
||
marking nsbeta3++, P1
Priority: P2 → P1
Whiteboard: [nsbeta3+][PDTP2] → [nsbeta3++][PDTP2]
Comment 19•24 years ago
|
||
PDT: upgrading to PDTP1 as intended earlier.
Whiteboard: [nsbeta3++][PDTP2] → [nsbeta3++][PDTP1]
Comment 20•24 years ago
|
||
Folks, are we going to check this patch in? This bug is killing me.
Comment 22•24 years ago
|
||
I was gone over the weekend. I'll try to get it in today.
Comment 23•24 years ago
|
||
Comment 24•24 years ago
|
||
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.
Comment 25•24 years ago
|
||
*** Bug 54138 has been marked as a duplicate of this bug. ***
Comment 26•24 years ago
|
||
*** Bug 54196 has been marked as a duplicate of this bug. ***
Comment 27•24 years ago
|
||
*** Bug 54196 has been marked as a duplicate of this bug. ***
Comment 28•24 years ago
|
||
*** Bug 54202 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•24 years ago
|
Assignee: joki → nisheeth
Status: ASSIGNED → NEW
Whiteboard: [nsbeta3++][PDTP1] → [nsbeta3++][PDTP1][ETA - 9/26]
Assignee | ||
Comment 29•24 years ago
|
||
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.
Comment 30•24 years ago
|
||
*** Bug 54240 has been marked as a duplicate of this bug. ***
Comment 31•24 years ago
|
||
Nisheeth, Can you check in joki's fix into the tree today? Looks like both the
trees are open now!! Thanks!!
Comment 32•24 years ago
|
||
add scott and myself to cc list - want to verify this fixes another site with a
similar stack trace.
Comment 33•24 years ago
|
||
*** Bug 48371 has been marked as a duplicate of this bug. ***
Comment 35•24 years ago
|
||
Please also check it into the truck ASAP.
Comment 36•24 years ago
|
||
*** Bug 53969 has been marked as a duplicate of this bug. ***
Comment 37•24 years ago
|
||
is this in the trunk yet?
Assignee | ||
Comment 38•24 years ago
|
||
Checked into the trunk. Marking bug fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 39•24 years ago
|
||
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.
Comment 40•24 years ago
|
||
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.
Comment 41•24 years ago
|
||
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.
Comment 42•24 years ago
|
||
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
Comment 43•24 years ago
|
||
*** Bug 54420 has been marked as a duplicate of this bug. ***
Comment 44•24 years ago
|
||
Comment 45•24 years ago
|
||
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 46•24 years ago
|
||
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.
Assignee | ||
Comment 47•24 years ago
|
||
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.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 48•24 years ago
|
||
Marking verified based on QA comments above.
Status: RESOLVED → VERIFIED
Comment 49•24 years ago
|
||
*** Bug 54847 has been marked as a duplicate of this bug. ***
Comment 50•24 years ago
|
||
*** Bug 53642 has been marked as a duplicate of this bug. ***
Updated•13 years ago
|
Crash Signature: [@ nsBindingManager::WalkRules]
Updated•6 years ago
|
Component: Event Handling → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•