[Webkit-unassigned] [Bug 261056] AX: Expose accessibility attributes for inline text predictions

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Sep 6 09:08:36 PDT 2023


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

--- Comment #9 from Joshua Hoffman <jhoffman23 at apple.com> ---
Comment on attachment 467565
  --> https://bugs.webkit.org/attachment.cgi?id=467565
Patch

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

>> Source/WebCore/accessibility/ios/AccessibilityObjectIOS.mm:231
>> +        return;
> 
> Would it make sense to move this early-return check before doing the work on this block (maybe with the attributedString nil check)? Seems like the result isn't used if &node != editor.compositionNode().

When we are getting a completed word, the previous composition will have ended, so the node we are looking at will not be equal to the compositionNode of the editor. We need them to be equal only when parsing presented (and incomplete) completions.

>> Source/WebCore/editing/Editor.cpp:2348
>> +                for (size_t pos = previousCompositionNodeText.length() - 1; pos > 0; pos--) {
> 
> This should probably be position instead of pos.
> 
> Also:
> size_t pos = previousCompositionNodeText.length() - 1
> 
> if previousCompositionNodeText.length() is zero, subtracting one from it (an unsigned value) will wrap to the max unsigned value, causing pos to be very big, in turn causing an out-of-bounds access on previousCompositionNodeText[pos].
> 
> Is it guaranteed that this length will not be zero? Or can we make this safer somehow?

I can guard against the length of that text earlier.

-- 
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/20230906/03200b23/attachment.htm>


More information about the webkit-unassigned mailing list