Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: a6a7f32de48b875cfbfa2bdbf6877e2f84e315ae
https://github.com/WebKit/WebKit/commit/a6a7f32de48b875cfbfa2bdbf6877e2f84e315ae
Author: Alan Baradlay <[email protected]>
Date: 2025-12-03 (Wed, 03 Dec 2025)
Changed paths:
A
LayoutTests/fast/inline/blocks-in-inline-layout-with-margin-after3-expected.html
A LayoutTests/fast/inline/blocks-in-inline-layout-with-margin-after3.html
M Source/WebCore/layout/formattingContexts/block/BlockLayoutState.h
M Source/WebCore/layout/formattingContexts/inline/AbstractLineBuilder.h
M
Source/WebCore/layout/formattingContexts/inline/InlineFormattingContext.cpp
M Source/WebCore/layout/formattingContexts/inline/InlineLineBuilder.cpp
M
Source/WebCore/layout/formattingContexts/inline/display/InlineDisplayLineBuilder.cpp
M
Source/WebCore/layout/formattingContexts/inline/display/InlineDisplayLineBuilder.h
M
Source/WebCore/layout/integration/LayoutIntegrationFormattingContextLayout.cpp
Log Message:
-----------
[blocks-in-inline] Fix
fast/block/margin-collapse/block-inside-inline/006.html -010.html -012.html and
-018.html
https://bugs.webkit.org/show_bug.cgi?id=303420
Reviewed by Antti Koivisto.
MarginInfo's margin value after laying out the block content [a] -coming back
from render tree layout,
is not necessarily [a]'s after margin, instead it is an input to the subsequent
margin collapsing
which could happen between [a] and the subsequent
1. inline content
<span>
<div style="margin-bottom: 100px">text</div>
content
</span>
forming a 100px gap between the middle block and inline content (IFC should
be able to handle it internally)
2. block content
<span>
<div style="margin-bottom: 100px">text</div>
<span></span>
<div></div>
content
</span>
forming a 100px gap between the the 2 block containers (so it is input back
to render tree layout)
3. root block's after side
<div>
<span>
<div style="margin-bottom: 100px"></div>
</span>
</div>
handled in render tree layout in handleAfterSideOfBlock
so instead of setting 'margin after' proactively on our block container, we
move the line vertically as needed.
This is similar to what block layout does when computing 'estimated top
position' (see FIXME).
Test: fast/inline/blocks-in-inline-layout-with-margin-after3.html
*
LayoutTests/fast/inline/blocks-in-inline-layout-with-margin-after3-expected.html:
Added.
* LayoutTests/fast/inline/blocks-in-inline-layout-with-margin-after3.html:
Added.
* Source/WebCore/layout/formattingContexts/block/BlockLayoutState.h:
(WebCore::Layout::BlockLayoutState::MarginState::resetBeforeSideOfBlock):
* Source/WebCore/layout/formattingContexts/inline/AbstractLineBuilder.h:
(WebCore::Layout::AbstractLineBuilder::blockLayoutState):
* Source/WebCore/layout/formattingContexts/inline/InlineFormattingContext.cpp:
(WebCore::Layout::handleAfterSideMargin):
(WebCore::Layout::InlineFormattingContext::lineLayout):
(WebCore::Layout::InlineFormattingContext::updateLayoutStateWithLineLayoutResult):
* Source/WebCore/layout/formattingContexts/inline/InlineLineBuilder.cpp:
(WebCore::Layout::LineBuilder::placeInlineAndFloatContent):
*
Source/WebCore/layout/formattingContexts/inline/display/InlineDisplayLineBuilder.cpp:
(WebCore::Layout::InlineDisplayLineBuilder::hasTrailingLineWithBlockContent):
(WebCore::Layout::InlineDisplayLineBuilder::trailingLineWithBlockLevelBox):
Deleted.
(WebCore::Layout::InlineDisplayLineBuilder::adjustLineBlockAfterSideWithCollapsedMargin):
Deleted.
Since we don't set margin after proactively, there's nothing to remove (shrink
line) when
the margin belongs to the root block itself (for further collapsing).
*
Source/WebCore/layout/formattingContexts/inline/display/InlineDisplayLineBuilder.h:
*
Source/WebCore/layout/integration/LayoutIntegrationFormattingContextLayout.cpp:
(WebCore::LayoutIntegration::layoutWithFormattingContextForBlockInInline):
Canonical link: https://commits.webkit.org/303831@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
