Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 3e83f90e9fae6a074aefa76c8054b0d97b7a80b6
https://github.com/WebKit/WebKit/commit/3e83f90e9fae6a074aefa76c8054b0d97b7a80b6
Author: Alan Baradlay <[email protected]>
Date: 2025-12-10 (Wed, 10 Dec 2025)
Changed paths:
A
LayoutTests/fast/block/inside-inlines/float-and-block-inside-inline-box-crash-expected.txt
A
LayoutTests/fast/block/inside-inlines/float-and-block-inside-inline-box-crash.html
M Source/WebCore/layout/formattingContexts/inline/InlineLineBuilder.cpp
M Source/WebCore/layout/formattingContexts/inline/InlineLineBuilder.h
Log Message:
-----------
[blocks-in-inline] Crash when visiting amazon.com product page
https://bugs.webkit.org/show_bug.cgi?id=303875
<rdar://166147838>
Reviewed by Antti Koivisto.
This crash is caused by unbalanced inline-box start/end pairs after block and
float content with margin.
LineBox expects balanced inline box start/end pairs (the result of line
breaking).
This balance can either just come out of line breaking naturally e.g.
<span>text</span>
where both [<span>] and [</span>] are part of the same line breaking result.
or by constructing LineSpanningInlineBoxStart for unbalanced start/end pairs
e.g.
<span>t<br>ext</span>
where the second line would only contain the inline box end [</span>] and to
fix that
we construct a (fake) spanning start inline item when initializing the line.
This got broken by re-running line layout after margin handling.
In cases when we realize that initial line constraints may be incorrect due to
the combination of
margin and intrusive floats, we re-run layout for the current candidate content.
It essentially means we clear the line, move it vertically and re-apply the
candidate content.
The (incorrect) assumption here was that the line is always completely empty
when we got here and we just need to re-apply the line candidate content.
This assumption is true for most of the time as we run this logic when the line
becomes contentful -which is normally the first content on the line.
e.g. <span>text</span> more text
we apply this logic when we put [<span>text</span>] on the line.
However floats force us to "break" the inline item sequence in-between inline
content.
e.g. <span><float box>text</span> more text
while there's no soft-wrap opportunity between [span] and [text], [float-box]
breaks this continuous set of runs and
we end up placing the inline box start [span] as a single item before getting
to the contentful part of the set [text]).
As we get to [text], we realize we need to re-run layout here, and as we reset
the line we lose the (non-contenful) preceding content ([span])
causing unbalanced start/end pair.
This fix includes:
1. Move inline handling code from placeInlineAndFloatContent to a dedicated
function
2. Ensure that the line has all the content when re-running layout. (See
precedingNonContentfulContent).
Test: fast/block/inside-inlines/float-and-block-inside-inline-box-crash.html
*
LayoutTests/fast/block/inside-inlines/float-and-block-inside-inline-box-crash-expected.txt:
Added.
*
LayoutTests/fast/block/inside-inlines/float-and-block-inside-inline-box-crash.html:
Added.
* Source/WebCore/layout/formattingContexts/inline/InlineLineBuilder.cpp:
(WebCore::Layout::LineBuilder::placeInlineAndFloatContent):
(WebCore::Layout::LineBuilder::handleInlineContent):
(WebCore::Layout::LineBuilder::applyLineBreakingOnCandidateInlineContent):
* Source/WebCore/layout/formattingContexts/inline/InlineLineBuilder.h:
Canonical link: https://commits.webkit.org/304230@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
