Closed
Bug 398205
Opened 17 years ago
Closed 17 years ago
InvalidateChildren() on the ancestor with accessible when a node has no accessible
Categories
(Core :: Disability Access APIs, defect)
Core
Disability Access APIs
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: aaronlev, Assigned: aaronlev)
References
Details
(Keywords: access)
Attachments
(1 file)
Right now we can have a situation like this:
Ancestor --> accessible
\--Child --> no corresponding accessible
If the child is shown or hidden, the first ancestor with an accessible needs to have InvalidateChildren() called for it.
Currently SHOW or HIDE events cause InvalidateChildren() to be called in FlushPendingEvents(). This means it's on a delay until after the dom is finished changing.
I suggest that we fire an EVENT_INTERNAL_INVALIDATE_CHILDREN on the correct node from ::InvalidateCacheSubtree(), and that FlushPendingEvents process that. We can just call it at the end of that method, and it has the extra advantage that we don't need to call it twice for the SIGNIFICANT_CHANGE events (right now the InvalidateChildren() will happen once for both the SHOW and HIDE those cause).
Assignee | ||
Comment 1•17 years ago
|
||
I believe this is the true fix for bug 394198 (and it should be done after bug 393660 is finished).
Depends on: 393660
Assignee | ||
Updated•17 years ago
|
Summary: InvalidateChildren() on the parent with accessible when a node has no children → InvalidateChildren() on the ancestor with accessible when a node has no accessible
Assignee | ||
Updated•17 years ago
|
Blocks: fox3access
Assignee | ||
Updated•17 years ago
|
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
Assignee | ||
Comment 3•17 years ago
|
||
I want to take the specific part for this bug from the patch in bug 398021 and do it separately.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Assignee | ||
Comment 4•17 years ago
|
||
Surkov, I think this is safer than my idea of a new event. It just changes how SHOW/HIDE are dealt with.
We should be able to check this in separately from the fix for bug 398021.
Then, I think for bug 398021 if we decide to pursue a "frozen state" we can look for these events in the event queue.
Attachment #285275 -
Flags: review?(surkov.alexander)
Comment 5•17 years ago
|
||
What's difference between old and new code for hide events?
Comment 6•17 years ago
|
||
Probably it's worth to change if (domNode) on assertion because domNode can't be null, right?
Comment 7•17 years ago
|
||
it's not related with the patch but
in flushPendingEvents we fire new events
FireShowHideEvents(domNode, eventType, PR_FALSE, isFromUserInput);
When will these events be processed?
Assignee | ||
Comment 8•17 years ago
|
||
We still need to get the part of the fix in bug 398205 reviewed so we can separately see if it affects anything. Can we do that right away please please? :)
Assignee | ||
Comment 9•17 years ago
|
||
I've been thinking, I'm not sure why we need this fix.
If you have a show or hide on a child with no accessible:
Ancestor --> accessible
\--Child --> no corresponding accessible
If it has no accessible descendants anyway, nothing needs to happen to the ancestor with the accessible.
If it does have accesible descendants, then FireShowHideEvents() should happen. That means FlushPendingEvents() will get show hide events and InvalidateChildren() on the ancestor anyway.
So why do we need this fix? And how did bug 394198 really happen if this is true?
BTW please ignore comment 8.
Comment 10•17 years ago
|
||
(In reply to comment #9)
> If it does have accesible descendants, then FireShowHideEvents() should happen.
> That means FlushPendingEvents() will get show hide events and
> InvalidateChildren() on the ancestor anyway.
>
> So why do we need this fix? And how did bug 394198 really happen if this is
> true?
>
EVENT_ASYNCH_HIDE didn't get fired because no corresponding accessible for the child was found.
Comment 11•17 years ago
|
||
(In reply to comment #10)
> > So why do we need this fix? And how did bug 394198 really happen if this is
> > true?
> >
> EVENT_ASYNCH_HIDE didn't get fired because no corresponding accessible for the
> child was found.
>
And that should have been fixed in bug 393660
Assignee | ||
Comment 12•17 years ago
|
||
EVENT_ASYNCH_HIDE in fact does get fired for descendants of the <body> which is hidden. This causes InvalidateChildren() to be called on the doc accessible. All of that is working correctly, so this bug is WONTFIX.
The core issue for bug 394198 is still slightly different.
Status: REOPENED → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → WONTFIX
Comment 13•17 years ago
|
||
(In reply to comment #12)
> The core issue for bug 394198 is still slightly different.
>
Aaron, could you give more detail on this?
Updated•17 years ago
|
Attachment #285275 -
Flags: review?(surkov.alexander)
You need to log in
before you can comment on or make changes to this bug.
Description
•