Closed
Bug 358722
Opened 18 years ago
Closed 15 years ago
Crashes [@ nsDocAccessibleWrap::FireToolkitEvent]
Categories
(Core :: Disability Access APIs, defect)
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]
Reporter | ||
Comment 1•18 years ago
|
||
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?
Comment 2•18 years ago
|
||
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-
Updated•18 years ago
|
Flags: wanted1.8.1.x+
Reporter | ||
Comment 3•18 years ago
|
||
This is getting higher in the trunk crasher list.
Keywords: topcrash
Comment 4•18 years ago
|
||
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.
Comment 5•18 years ago
|
||
Actually I think the fix was not ultimately just from the changes in bug 353200, but also required some core layout changes -- bug 354745.
Comment 7•18 years ago
|
||
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.
Comment 8•18 years ago
|
||
Does this still even occur on branch?
Assignee: aaronleventhal → mats.palmgren
Comment 9•18 years ago
|
||
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
Comment 10•17 years ago
|
||
Mats, I still see 4 crashes like this in the build 2007072518
http://talkback-public.mozilla.org/search/start.jsp?search=1&searchby=stacksig&match=contains&searchfor=FireToolkitEvent&vendor=MozillaOrg&product=Firefox2&platform=Win32&buildid=2007072518&sdate=07%2F04%2F2007&stime=&edate=09%2F15%2F2007&etime=&sortby=bbid&rlimit=500
So it doesn't look like this is fixed completely.
Updated•17 years ago
|
Blocks: fox3access
Comment 11•17 years ago
|
||
Not an issue in FF3. Not sure what the fix is for the 1.8 branch.
No longer blocks: fox3access
Comment 12•16 years ago
|
||
(In reply to comment #11)
> Not an issue in FF3. Not sure what the fix is for the 1.8 branch.
worksforme, wontifx?
Comment 13•16 years ago
|
||
Alex, is this bug 448594?
Comment 14•16 years ago
|
||
(In reply to comment #13)
> Alex, is this bug 448594?
Stefan Sitter said it's different in bug 448594 comment #4.
Comment 15•16 years ago
|
||
Mass un-assigning bugs assigned to Aaron.
Assignee: aaronleventhal → nobody
Comment 16•15 years ago
|
||
Can anyone find any recent occurrences in crash-stats?
Comment 17•15 years ago
|
||
No crashes at nsDocAccessibleWrap::FireToolkitEvent within the last week.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
Assignee | ||
Updated•14 years ago
|
Crash Signature: [@ nsDocAccessibleWrap::FireToolkitEvent]
You need to log in
before you can comment on or make changes to this bug.
Description
•