Closed
Bug 434445
Opened 17 years ago
Closed 14 years ago
freeze the accessible tree
Categories
(Core :: Disability Access APIs, defect)
Core
Disability Access APIs
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: surkov, Unassigned)
References
(Blocks 1 open bug)
Details
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•17 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 | ||
Comment 2•14 years ago
|
||
Wontfix, now we update the tree once we're notified about DOM changes (bug 570275).
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
Reporter | ||
Updated•14 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•