[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 #15 from zalan <zalan at apple.com> ---
(In reply to Nan Wang from comment #13)
> (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.
Reparenting is not very uncommon in the rendering code. How do you handle first letter or column changes? They are very similar to what you just described here.

-- 
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/20170810/62bd329c/attachment.html>