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)

Product:
Core
Component:
Disability Access APIs
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: aaronlev, Assigned: aaronlev)

References

Details

(Keywords: access)

Attachments

(1 file)

Not a new event, but a safe solution to allow invalidation on ancestor when node has no accessible
3.80 KB, patch
Details | Diff | Splinter Review 
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).
I believe this is the true fix for bug 394198 (and it should be done after bug 393660 is finished).
Depends on: 393660
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
Blocks: fox3access
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
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 → ---
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)
What's difference between old and new code for hide events?
Probably it's worth to change if (domNode) on assertion because domNode can't be null, right?
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?
Depends on: 398021
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? :)
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.
Blocks: 398021
No longer depends on: 398021
(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.
(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
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
(In reply to comment #12)
> The core issue for bug 394198 is still slightly different.
> 
Aaron, could you give more detail on this?
Attachment #285275 - Flags: review?(surkov.alexander)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: