Currently, only nsRootAccessible can fire events to nsIAccessibleListener, but some listeners need to be registered in an individual accObject, for instance, nsIEditActionListener, so we must be able to fire events from such kind of accObject. That's not hard to do - add a handleEvent() into nsIAccessble, each object pass the call to its parent, till reached the nsRootAccessible.
Created attachment 114869 [details] [diff] [review] patch also get rid of the unnecessary declaration of AccessibleEventData. the patch seems long, but most of them is the string replacement.
Kyle, if an object like a textfield is responsible for firing it's own events, what guarantees that it currently exists? In other words, if the screen reader releases the leaf object which is generating events, won't it stop firing them?
for the textfield case, I'll call nsIEditor::AddEditActionListener in its constructor, and RemoveEditActionListener in destructor, that could guarantee the object won't be released during the event life cycle. Or, is there any possobility to add such listener in nsRootAccessible? I need the edit-action-listener because: 1) some dom events do not perfectly match the ATK needs. 2) I'm working on accessibility of Composer that does not fire general events while typing.
Comment on attachment 114869 [details] [diff] [review] patch Okay, you're right. http://lxr.mozilla.org/seamonkey/source/editor/libeditor/base/nsEditor.cpp#1637 It looks like nsEditor keeps a strong reference to the edit action listeners. r=aaronl
Attachment #114869 - Flags: review?(aaronl) → review+
Comment on attachment 114869 [details] [diff] [review] patch sr=Henry
Attachment #114869 - Flags: superreview?(Henry.Jia) → superreview+
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.