[webkit-changes] [WebKit/WebKit] 7cac26: (REGRESSION 264248 at main) [IFC] ASSERT_NOT_REACHED ...
Alan Baradlay
noreply at github.com
Wed Jul 19 05:48:49 PDT 2023
Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 7cac269045d9afabc7f4def4e4d4497d811c4cdf
https://github.com/WebKit/WebKit/commit/7cac269045d9afabc7f4def4e4d4497d811c4cdf
Author: Alan Baradlay <zalan at apple.com>
Date: 2023-07-19 (Wed, 19 Jul 2023)
Changed paths:
A LayoutTests/fast/inline/intrusive-float-coming-from-overflowing-sibling-expected.html
A LayoutTests/fast/inline/intrusive-float-coming-from-overflowing-sibling.html
M Source/WebCore/layout/formattingContexts/inline/InlineFormattingGeometry.cpp
M Source/WebCore/layout/formattingContexts/inline/InlineLineBuilder.cpp
M Source/WebCore/layout/formattingContexts/inline/InlineLineBuilder.h
Log Message:
-----------
(REGRESSION 264248 at main) [IFC] ASSERT_NOT_REACHED in InlineFormattingGeometry::logicalTopForNextLine
https://bugs.webkit.org/show_bug.cgi?id=259250
<rdar://problem/112338580>
Reviewed by Antti Koivisto.
Thanks to https://next.dk/beregn/nybil/1/indtast-nummerplade, a state which was treated as unexpected, can now be handled properly.
An intrusive float (coming from a sibling/parent BFC) previously was always assumed to being intrusive starting from the IFC boundary (aka. 0px vertically local to IFC)
e.g.
<div>
<div id=previous>
some inline content
<div id=tall_and_wide_intrusive_float></div>
</div>
<div id=ifc>
This content is constrained by the float
</div>
</div>
[ifc] sees the intrusive float starting at the local 0px vertical position.
_______
|some |
|inline | <- [previous] block box
|content|
| ____ |
|| | |
||____|_|
______________________ <- this is [ifc]'s 0px vertical position where the intrusive float "starts".
|| | This content is|
|| | constrained by |
|| | the float |
|| | |
||____| |
| |
| |
|______________________|
However there are cases when the intrusive float actually "starts" with an offset inside the sibling IFC e.g.
<div>
<div id=previous style="width: 10px; height: 50px>
some inline content
<div id=tall_and_wide_intrusive_float></div>
</div>
<div id=ifc>
This content is constrained by the float
</div>
</div>
With a very short (both horizontally and vertically, notice the relevant CSS properties) [previous] block, and an overflowing float box, it may start well beyond the local 0px vertical position of [ifc]
_______
|some |
|inline | <- [previous] block box, notice the overflow content
-------_______________
|contenttent is | <- and this is [ifc]'s 0px vertical position where content from [previous] block box overlaps [ifc] content
| ____ |
|| | constrained | <- this is where the intrusive float starts with an offset.
|| | by the float |
|| | |
|| | |
|| | |
|| | |
||____| |
| |
| |
|______________________|
In such cases, we may not be able to place a (tall) inline content at the vertical position 0px (due to the intrusive float), producing empty line while we fail to find
such floats at InlineFormattingGeometry::logicalTopForNextLine when applying short line height (see computedLineHeight()).
This fix ensures that we use the exact same vertical extent to find floats what prevented us from placing any content on the previous line.
* LayoutTests/fast/inline/intrusive-float-coming-from-overflowing-sibling-expected.html: Added.
* LayoutTests/fast/inline/intrusive-float-coming-from-overflowing-sibling.html: Added.
* Source/WebCore/layout/formattingContexts/inline/InlineFormattingGeometry.cpp:
(WebCore::Layout::InlineFormattingGeometry::logicalTopForNextLine const): use ceil to make sure we always starts at a integral position in this unexpected case.
* Source/WebCore/layout/formattingContexts/inline/InlineLineBuilder.cpp:
(WebCore::Layout::LineBuilder::layoutInlineContent):
(WebCore::Layout::LineBuilder::initialize):
(WebCore::Layout::LineBuilder::handleInlineContent):
* Source/WebCore/layout/formattingContexts/inline/InlineLineBuilder.h:
Canonical link: https://commits.webkit.org/266159@main
More information about the webkit-changes
mailing list