Closed Bug 358722 Opened 18 years ago Closed 15 years ago

Crashes [@ nsDocAccessibleWrap::FireToolkitEvent]

Categories

(Core :: Disability Access APIs, defect)

1.8 Branch
x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: smaug, Unassigned)

References

()

Details

(Keywords: topcrash)

Crash Data

#62 in FF2 topcrashers list. nsDocAccessibleWrap::FireToolkitEvent [mozilla/accessible/src/msaa/nsDocAccessibleWrap.cpp, line 260] nsAccessible::FireToolkitEvent [mozilla/accessible/src/base/nsAccessible.cpp, line 1757] nsHTMLLinkAccessible::FireToolkitEvent [mozilla/accessible/src/html/nsHTMLLinkAccessible.cpp, line 104] nsRootAccessible::FireAccessibleFocusEvent [mozilla/accessible/src/base/nsRootAccessible.cpp, line 486] nsRootAccessible::HandleEvent [mozilla/accessible/src/base/nsRootAccessible.cpp, line 757] nsRootAccessible::Focus [mozilla/accessible/src/base/nsRootAccessible.cpp, line 982] nsEventListenerManager::HandleEvent [mozilla/content/events/src/nsEventListenerManager.cpp, line 1752] nsXULDocument::HandleDOMEvent [mozilla/content/xul/document/src/nsXULDocument.cpp, line 1235] nsXULElement::HandleDOMEvent [mozilla/content/xul/content/src/nsXULElement.cpp, line 2211]
Also some of the crashes with stack signature 0x00000000 are apparently this same bug. 0x00000000 nsDocAccessibleWrap::FireToolkitEvent [mozilla/accessible/src/msaa/nsDocAccessibleWrap.cpp, line 260] nsAccessible::FireToolkitEvent [mozilla/accessible/src/base/nsAccessible.cpp, line 1757] nsDocAccessible::InvalidateCacheSubtree [mozilla/accessible/src/base/nsDocAccessible.cpp, line 1098] nsDocAccessible::ContentRemoved [mozilla/accessible/src/base/nsDocAccessible.cpp, line 906] nsHTMLDocument::ContentRemoved [mozilla/content/html/document/src/nsHTMLDocument.cpp, line 1181] nsGenericElement::RemoveChildAt [mozilla/content/base/src/nsGenericElement.cpp, line 2908] nsContentOrDocument::RemoveChildAt [mozilla/content/base/src/nsGenericElement.cpp, line 2962] nsGenericElement::doReplaceOrInsertBefore [mozilla/content/base/src/nsGenericElement.cpp, line 3587] nsGenericElement::InsertBefore [mozilla/content/base/src/nsGenericElement.cpp, line 3067]
Flags: blocking1.8.1.1?
Would be nice to get a fix, but no patch and not even a testcase. Not blocking, but we'd look at a patch.
Flags: wanted1.8.1.x+
Flags: blocking1.8.1.1?
Flags: blocking1.8.1.1-
Flags: wanted1.8.1.x+
This is getting higher in the trunk crasher list.
Keywords: topcrash
I believe this relates to broken caching of frames in links and text nodes. The frame is cached but doesn't get invalidated when it should be. This was fixed for trunk in bug 353200. The patch says "Possible fix" but it does seem to have fixed it on trunk.
Actually I think the fix was not ultimately just from the changes in bug 353200, but also required some core layout changes -- bug 354745.
Ultimately we had to remove frame caching for links and text nodes: See bug 376924. If anything, that's the change we would want to take for branch at this point.
Does this still even occur on branch?
Assignee: aaronleventhal → mats.palmgren
I also think this is probably caused by a cached deleted frame, which should now be fixed. We currently have 3054 Talkback crashes with nsDocAccessibleWrap::FireToolkitEvent on the stack. There are 5 from trunk builds, all are dated before 2007-04-12 when bug 376924 was fixed on trunk. Looking at the reported URLs it looks like http://www.guardian.co.uk and http://www.deviantart.com are the most frequent. I can't crash either of those sites in a Linux branch 1.8 debug build. We should probably keep the bug open until a month after 2.0.0.5/1.5.0.13 has been released just to verify that there are no new crash reports. I'm not sure how to handle that in Bugzilla, reassign it to a QA person?
Assignee: mats.palmgren → aaronleventhal
Blocks: fox3access
Not an issue in FF3. Not sure what the fix is for the 1.8 branch.
No longer blocks: fox3access
(In reply to comment #11) > Not an issue in FF3. Not sure what the fix is for the 1.8 branch. worksforme, wontifx?
Alex, is this bug 448594?
(In reply to comment #13) > Alex, is this bug 448594? Stefan Sitter said it's different in bug 448594 comment #4.
Mass un-assigning bugs assigned to Aaron.
Assignee: aaronleventhal → nobody
Can anyone find any recent occurrences in crash-stats?
No crashes at nsDocAccessibleWrap::FireToolkitEvent within the last week.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
Crash Signature: [@ nsDocAccessibleWrap::FireToolkitEvent]
You need to log in before you can comment on or make changes to this bug.