Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 7cac269045d9afabc7f4def4e4d4497d811c4cdf
https://github.com/WebKit/WebKit/commit/7cac269045d9afabc7f4def4e4d4497d811c4cdf
Author: Alan Baradlay <[email protected]>
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@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
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
