Closed
Bug 494109
Opened 15 years ago
Closed 14 years ago
keep accessibles alive until event is fired
Categories
(Core :: Disability Access APIs, defect)
Core
Disability Access APIs
Tracking
()
RESOLVED
FIXED
People
(Reporter: surkov, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: access)
the scenario is
1) add child node
2) remove previous child node
3) parent accessible is invalidated (because we got add DOM node event)
4) removed accessible has no parent
I think it leads to bug 493531.
We definitely need to keep accessible alive until we fired event, otherwise if AT needs something more on hide event than its cache invalidation then it will fail.
Reporter | ||
Comment 1•15 years ago
|
||
List of bugs might be affected by this fix: bug 412931, bug 408997, bug 394493, bug 405679, bug 397112, bug 398021.
Comment 2•15 years ago
|
||
This bug sounds right. Do you have a plan/wip?
Reporter | ||
Comment 3•15 years ago
|
||
no plans, no wips just few tries and one problem keeps another one.
Comment 4•15 years ago
|
||
I think we can use the recent work on bug 467144 for this. Check to see if the removal is in a live region, and save the data we need, and do whatever updating we need (cache etc), after we've fired our events.
Depends on: 467144
Comment 5•15 years ago
|
||
Sorry last comment was really meant for bug 488053
Reporter | ||
Comment 6•14 years ago
|
||
This bug should have been fixed by bug 570275. Need to check.
Reporter | ||
Comment 7•14 years ago
|
||
(In reply to comment #6)
> This bug should have been fixed by bug 570275. Need to check.
confirm fixed.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•