[Webkit-unassigned] [Bug 161276] AX: Crash at AccessibilityRenderObject::computeAccessibilityIsIgnored const + 552

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Aug 31 00:06:40 PDT 2016


--- Comment #9 from Nan Wang <n_wang at apple.com> ---
(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> > > Maybe we can just do
> > > 
> > > RenderObject protect(mrenderer)
> > > 
> > > Then access it everywhere with
> > > 
> > > protect.isBR() and likewise with dot operator
> > > 
> > 
> > Why would this work? A reference is just an alia of the object and the
> > object can still be nulled during this function, right? And C++ has
> > undefined behavior on null reference, it will also cause crash?
> I see a number of examples like this
>    Ref<Element> protect(*element);
>     bool successfullyFocused = newDocument->setFocusedElement(element,
> direction);
> It seems however, if we do 
> RenderObject protect(m_renderer)
> and then access protect, as an object that would solve our problem. Our
> problem is now that the pointer inside m_renderer is bad, but rather what
> m_renderer points to. If we copy what m_renderer pointed to and use that for
> the duration of the method, it seems like that would work

I think for the other example, the class is ref counted so we can use Ref<T> to hold onto the object. 
Copying the object itself seems fine but would it affect the performance since we are calling this function everywhere? Also when I try to copy the object there's an compiler error saying RenderObject is an abstract class. Maybe we have to copy the derived class object? But that makes this problem more complicated.

You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160831/882caef0/attachment.html>

More information about the webkit-unassigned mailing list