[Webkit-unassigned] [Bug 175340] AX: crash at WebCore::AccessibilityObject::supportsARIALiveRegion() const + 24

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=175340

--- Comment #13 from Nan Wang <n_wang at apple.com> ---
(In reply to zalan from comment #12)
> (In reply to Nan Wang from comment #11)
> > (In reply to zalan from comment #8)
> > > I am not sure if this patch is correct. Just because some element becomes
> > > floating (or non-floating) it does not mean it's stale. They become stale
> > > when we detached them from the tree/destroy them. 
> > > 
> > > What exactly do you mean by "When adding a psuedo element child to a
> > > RenderBlockFlow element, there might be a chance where the element has
> > > already been relayout but we are still holding onto its stale children."
> > > What is the stale child in this context? The pseudo element's RenderInline?
> > > 
> > > "by notifying AX correctly when inserting/removing children during layout"
> > > the floating object map is an internal helper container; Not sure why AX
> > > needs to know whether we add a renderer to a internal container.
> > > r-
> > 
> > I think there's something going on during layout process that invalidates
> > some of the RenderBlockFlow object's children. Do you think it would be
> > suitable to notify AX in layoutBlock?
> By invalidating you mean destroying the child renderer? In such cases, AX is
> already notified through ::willBedDestroyed.

The case here seems to be the child renderer is not attached to the same parent, so that AX is holding a stale tree. When we ask for the ax parent object from the child renderer it will then lead to accessing an invalid memory.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170809/1976ea4c/attachment.html>