[Webkit-unassigned] [Bug 121558] AX: Crash when trying to retrieve textual information for a heading after hiding it

[bugzilla-daemon at webkit.org]

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





--- Comment #2 from chris fleizach <cfleizach at apple.com>  2013-09-18 09:22:40 PST ---
(In reply to comment #0)
> While working on bug 121556, I found that the reason why it crashes in AccessibilityNodeObject::textUnderElement() is because some nodes in the accessibility tree are being detached between one iteration and the following one inside the for loop in that function.
> 
> More specifically too, the problem happens exactly after we call child->textUnderElement() in the snipped of code below:
> 
>     StringBuilder builder;
>     for  (AccessibilityObject* child = firstChild(); child; child = child->nextSibling()) {
> 
>         [...]
> 
>         String childText = child->textUnderElement(mode);
>         if (childText.length()) {
>             if (shouldAddSpaceBeforeAppendingNextElement(builder, childText))
>                 builder.append(' ');
>             builder.append(childText);
>         }
>     }
> 
> Before the call to child->textUnderElement(), and considering the accessibility/heading-level.html test as our scenario, a hypothetical call to child->nextSibling() might return 0x0, which is fine, suggesting that there no more children after that one. However, if we call again child->nextSibling() after the call to textUnderElement(), we get a beautiful segfault error, which is the crashing we are seeing in the bots.
> 
> After some investigation, I found that the reason for that seems to be that in r155378 a forced call to update the layout has been added to the constructor of the TextIterator, which is used in AccessibilityRenderObject::textUnderElement() for text objects. And while that addition seems to be correct according to the comments in bug 120891, it's also causing that in certain scenarios (like the one detected with this test) we have the accessibility tree being altered between iterations of that for loop, causing that the 'child' pointer that we have at the beginning of the iteration is no longer valid, thus leading to the crash.
> 

Are we able to force the layout update before we start building the string? hopefully then calls within the textUnderElement() won't do anything because it will already be updated

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.