[Webkit-unassigned] [Bug 236378] Check bidiLevels are valid before reordering

[bugzilla-daemon at webkit.org]

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

zalan <zalan at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #451397|review?, commit-queue?      |review+, commit-queue-
              Flags|                            |

--- Comment #2 from zalan <zalan at apple.com> ---
Comment on attachment 451397
  --> https://bugs.webkit.org/attachment.cgi?id=451397
Patch

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

> Source/WebCore/layout/formattingContexts/inline/InlineLineBuilder.cpp:350
> +
> +            // bidiLevels are required to be less than the MAX + 1, otherwise
> +            // ubidi_reorderVisual will silently fail.
> +            if (lineRuns[i].bidiLevel() > UBIDI_MAX_EXPLICIT_LEVEL + 1)
> +                continue;
> +

Great patch! What happens here is that 
1. an empty DOM text node (length = 0) generates an InlineTextItem with zero length
2. this InlineTextItem gets ignored at InlineItemsBuilder::breakAndComputeBidiLevels() -this is ok, it's hard to assign a bidi level for a 0 length content.
3. this zero length InlineTextItem enters the bidi reordering with the default UBIDI_DEFAULT_LTR value (254, see InlineItem's c'tor) which is greater than UBIDI_MAX_EXPLICIT_LEVEL (125)
I'd slightly change this patch by adding the following asserts 
ASSERT(lineRuns[I].bidiLevel() == UBIDI_DEFAULT_LTR);
ASSERT(!downcast<InlineTextItem>(lineRuns[I]).length());
as we do not expect any other type of content with such bidi level.

-- 
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/20220210/1213c4a7/attachment-0001.htm>