The problem is here - http://mxr.mozilla.org/mozilla-central/source/accessible/src/msaa/nsAccessibleWrap.cpp#1675 We trying to get parent accessible for invalidated accessible (in the case of DOM node removing), therefore we get document accessible here.

for information, this code goes from bug 290352, from times where we hadn't delayed events. So obviously we should reconsider the code. I think it's worth to try Marco's suggestion, search closest HWND for visible area.

So, that's what actually happen: 1) process removing of text node and pend hide event 2) process adding of text node, invalidate parent and null mParent of removed text node 3) process event for removed text node, try to get cached parent (fails), get parent DOM node (fails), get document accessible. 4) fire hide event for HWND of document accessible So there is no way to get closest visible HWND for removed text node. We should reconsider our logic or cache some data (like accessible parent or its HWND), I can't say I like second approach.

I didn't find any details how AccessibleObjectFromEvent works but it sends WM_GETOBJECT to accessible window where we return document accessible (or root accessible) always, then it looks like AccessibleObjectFromEvent uses childId passed into NotifyWinEvent and obtained document accessible to get event target. I don't understand how childId can be used but this scenario looks true. So I think the problem might be not in the fact we return HWND for document accessible, it might be because of accessible was invalidated already and there is no way to get it from childId.

I filed bug 494109 to keep accessibles alive unti we fired a11y event. I think that bug should fix this one.

Note we are going to have less and less HWNDs: http://weblogs.mozillazine.org/roc/archives/2009/06/native_widgets.html

This bug should have been fixed by bug 570275. Need to check.

(In reply to comment #6) > This bug should have been fixed by bug 570275. Need to check. confirm fixed.