Bug 209312 - [LFC][IFC] Bail out when busy looping on partial content
Summary: [LFC][IFC] Bail out when busy looping on partial content
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: zalan
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2020-03-19 15:13 PDT by zalan
Modified: 2020-03-20 07:59 PDT (History)
5 users (show)

See Also:


Attachments
Patch (6.49 KB, patch)
2020-03-19 20:01 PDT, zalan
no flags Details | Formatted Diff | Diff
Patch (6.49 KB, patch)
2020-03-20 07:32 PDT, zalan
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description zalan 2020-03-19 15:13:52 PDT
<rdar://problem/59954605>
Comment 1 zalan 2020-03-19 20:01:13 PDT
Created attachment 394059 [details]
Patch
Comment 2 Simon Fraser (smfr) 2020-03-19 20:09:22 PDT
Comment on attachment 394059 [details]
Patch

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

> Source/WebCore/ChangeLog:3
> +        [LFC][IFC] Bail out when busy looping on partial content

"Avoid infinite loop when..."

> Source/WebCore/ChangeLog:9
> +        Speculative fix to address busy looping/running out of inline run vector capacity at InlineFormattingContext::setDisplayBoxesForLine.

"busy looping" sounds like something that happens over time. Is it really an infinite loop?

> Source/WebCore/layout/inlineformatting/InlineFormattingContext.cpp:162
> +                // "sp<->litcontent" -> overflow length: 10 -> leading partial content length: 10.

Weird comment.

> Source/WebCore/layout/inlineformatting/InlineFormattingContext.cpp:175
> +                    ASSERT_NOT_REACHED();
> +                    // Move over to the next run if we are stuck on this partial content (when the overflow content length remains the same).
> +                    // We certainly lose some content, but we would be busy looping anyway.
> +                    previousLineEnd = PreviousLineEnd { trailingRunIndex, { } };
> +                    layoutRange.start = previousLineEnd->runIndex + 1;

Weird to assert and then run code.
Comment 3 zalan 2020-03-20 07:32:57 PDT
Created attachment 394081 [details]
Patch
Comment 4 EWS 2020-03-20 07:59:49 PDT
Committed r258761: <https://trac.webkit.org/changeset/258761>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 394081 [details].