freeze the accessible tree

RESOLVED WONTFIX

Status

()

RESOLVED WONTFIX
10 years ago
8 years ago

People

(Reporter: surkov, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

10 years ago
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

10 years ago
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 :)
(Reporter)

Updated

9 years ago
Blocks: 472809
(Reporter)

Comment 2

8 years ago
Wontfix, now we update the tree once we're notified about DOM changes (bug 570275).
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WONTFIX
(Reporter)

Updated

8 years ago
Blocks: 572951
No longer blocks: 472809
You need to log in before you can comment on or make changes to this bug.