[webkit-changes] [WebKit/WebKit] c17a7e: Very slow layout of flexbox containing overflow-wr...

[Alan Baradlay]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: c17a7e43925836ba9047cbf28ea92041fa472aed
      https://github.com/WebKit/WebKit/commit/c17a7e43925836ba9047cbf28ea92041fa472aed
  Author: Alan Baradlay <zalan at apple.com>
  Date:   2022-12-31 (Sat, 31 Dec 2022)

  Changed paths:
    M Source/WebCore/layout/formattingContexts/inline/InlineLineBuilder.cpp

  Log Message:
  -----------
  Very slow layout of flexbox containing overflow-wrap or word-break
https://bugs.webkit.org/show_bug.cgi?id=249909
<rdar://problem/103728723>

Reviewed by Antti Koivisto.

1. shrink-to-fit type of systems (flex, table, float, out-of-flow etc) trigger layout passes with horizontal available space of 0 (part of the preferred width computation)
2. "word-break: break-all" means let's break the content at arbitrary position.

This essentially means we break the text at the first (user perceived) character and fold the rest
of the text over to the next line and repeat until after we run out of text content (remember this is just the min width computation and not the final layout).
This is a somewhat common use case which we recognize and deal with it in way that we don't end up re-measuring the (overflowing)text over and over again.
This patch expands this optimization to cases when the text content is embedded in an inline box (e.g. <span>long text</span>).

* Source/WebCore/layout/formattingContexts/inline/InlineLineBuilder.cpp:
(WebCore::Layout::eligibleOverflowWidthAsLeading): Let's reuse the measured trailing content width as leading width even when the content is embedded in an inline box.

Canonical link: https://commits.webkit.org/258369@main