393237 - Minefield crashes while aaa:activedescendant points to an element with no accessible created for it

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Srinivas Annam]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070626 Minefield/3.0a6pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070626 Minefield/3.0a6pre

This crash happens with a tree application I have created which uses 'activedescendant' attribute that sets the active tree item. No crash if no screen reader is running. In this app, I have a typeahead feature that selects a tree item for the user typed characters. If the characters are typed very slowly the crash doesn't occur as frequently, whereas if you type the character at a regular speed the crash occurs quite often.

I believe the following is the crash report that this bug produced, I would re-test this and update the bug.

http://crash-stats.mozilla.com/report/list?range_unit=weeks&query_search=signature&query_type=contains&product=Firefox&platform=windows&version=Firefox%3A3.0a6pre&signature=nsAccessible%3A%3ARole%28nsIAccessible%2A%29&range_value=1

Reproducible: Sometimes

Steps to Reproduce:
1. use a tree sample with activedescendent and type ahead
2. type characters at regular speed to select the node
Actual Results:  
minefield crashes and produces a crash report (linked above)

Expected Results:  
not crash

The bug is most likely in the Accessibility layer (MSAA) of Mozilla.

Comment 1

[Marco Zehe (:MarcoZ)]

Please retest with a more recent Trunk build. Your build identifier shows that you are using Gran Paradiso alpha 6, which is two months old, and a lot has happened since then in the area of ARIA accessibility.

Comment 2

[Srinivas Annam]

Yes, it crashes with the latest nightly build as well. I have produced a brand new crash report with the new build i.e., Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007082111 Minefield/3.0a8pre

http://crash-stats.mozilla.com/report/list?range_unit=weeks&query_search=signature&query_type=contains&product=Firefox&platform=windows&version=Firefox%3A3.0a8pre&signature=nsAccessible%3A%3ARole(nsIAccessible*)&range_value=1

Comment 3

[Aaron Leventhal]

Ah, that crash report helps a lot. It's an obvious coding error, but it's a bug for both of us.

The element that activedescendant points to is a DOM node with no accessible object. It's probably a <span> or something which typically has no accessible created for it. I suggest putting a role attribute on it. Otherwise there is no accessible to fire focus events for it.

On our side, we need to do a null check.

Comment 4

[Aaron Leventhal]

Attachment: Null check!

Comment 5

[alexander :surkov (:asurkov)]

Comment on attachment 277841 [details] [diff] [review]
Null check!

r=me

Comment 6

[Srinivas Annam]

I have checked all my code and founds my items to be properly tagged with wairole:treeitem. As I originally mentioned this is a timing issue. 

One likely issue is because of the fact that treeitem is originally collapsed and just became visible and right after we are selecting it.

Some of this is based on my observation, where if I pre-open the treeitem and slowly type my characters the crash would not happen.

Comment 7

[Aaron Leventhal]

It would be hard to do a deeper fix on the timing issue without the testcase. If your testcase is private, I would love to try and convince you to build Mozilla (it's not so hard these days) and play around with it. If you submitted a patch it would be most appreciated.

Comment 8

[Srinivas Annam]

Yes, I have considered and still considering to build the Mozilla source myself. When I do I would certainly spend the time to debug and submit the patch. If time permits I will try this over the weekend.