[webkit-reviews] review granted: [Bug 174856] AX: Incorrect range from index and length in contenteditable with <p> tags : [Attachment 316437] patch

[bugzilla-daemon at webkit.org]

chris fleizach <cfleizach at apple.com> has granted Nan Wang <n_wang at apple.com>'s
request for review:
Bug 174856: AX: Incorrect range from index and length in contenteditable with
<p> tags
https://bugs.webkit.org/show_bug.cgi?id=174856

Attachment 316437: patch

https://bugs.webkit.org/attachment.cgi?id=316437&action=review




--- Comment #6 from chris fleizach <cfleizach at apple.com> ---
Comment on attachment 316437
  --> https://bugs.webkit.org/attachment.cgi?id=316437
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=316437&action=review

>>>>> Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapperMac.mm:3956
>>>>> + 	   return m_object->doAXStringForRange(plainTextRange);
>>>> 
>>>> is this not possible to fix in the characterOffsetForIndex? do you know
the reason?
>>> 
>>> I think the problem here is that for text controls, the AXValue comes from
the AccessibilityNodeObject::text() (we call
downcast<HTMLTextFormControlElement>(*node).value() or
downcast<Element>(node)->innerText()).
>>> This value can be different from what textIterator gives us. In this case
it will contain two newline characters instead of one visually.
>>> So when we try to get the range of text we should match that with the
entire element value.
>> 
>> does this need to be nativeTextControl() then? I think textControl also
pulls in role=textbox
> 
> I think isTextControl() is what we want, otherwise the problematic
contenteditable wouldn't be covered. nativeTextControl() only returns true for
form controls and <textarea>

ok so contenteitable also ends up using innerText() instead of a text iterator?