434445 - freeze the accessible tree

Status: RESOLVED WONTFIX

(Core :: Disability Access APIs, defect)

Description

[alexander :surkov (:asurkov)]

Original idea goes from bug 398021, patch 3. There was suggested to freeze the tree when DOM tree has been changed but accessible tree (which is invalidated in timeout). We get a case when we can continue the work with the accessible tree (navigation through the parent and children) but we can't do it correctly because DOM tree and accessible are out of sync.

There is another related issue or subissue. I mean the time when we fired an event to AT but we didn't invalidated the accessible tree. Here we get the same case described above. Partially it leads to an assertion when we try to calculate the parent of accessible which DOM node has been removed from the DOM tree (http://lxr.mozilla.org/mozilla/source/accessible/src/msaa/nsAccessibleWrap.cpp#1731). It's most harmless but annoying case.

We talked with Marco on irc about second case. He is agree to freeze the tree (to use cached accessibles only that time). But what about general freezing (the fist case)? Aaron what do you think?

Comment 1

[Aaron Leventhal]

Go ahead and try it after Firefox 3. We can create test builds and see what happens. I don't see a problem with it. But, I'll have to really think pretty hard to understand how it works, especially now that I'm less involved on a daily basis. So, I would appreciate a good diagram or wiki doc boiling down how it actually works. My IQ is not as high as it was when I started :)

Comment 2

[alexander :surkov (:asurkov)]

Wontfix, now we update the tree once we're notified about DOM changes (bug 570275).