RESOLVED FIXED245173
REGRESSION (iOS 16): Height of inline-block element in vertical-rl layout expands the root element width. 
https://bugs.webkit.org/show_bug.cgi?id=245173
Summary REGRESSION (iOS 16): Height of inline-block element in vertical-rl layout exp...
Takao Baba
Reported 2022-09-14 04:39:34 PDT
Created attachment 462330 [details] testcase Steps to reproduce: * Open attached testcase.html by Safari on iOS 16 in portrait mode. Expected behavior: * Horizontal overflow won't happen. The <h1> content is the device width (such as "980" for iPhone 13 Pro Max). Actual Behavior: * On iOS 16, the root element causes overflow. The <h1> will be over 3000. Environment: This looks a regression on iOS 16. iOS 15.6 works good. Note: The logical height (physical width) of the root element seems include the physical height of the inline-block element. The direction is opposite.
Attachments
testcase (322 bytes, text/html)
2022-09-14 04:39 PDT, Takao Baba 		no flags
Details
Patch (3.39 KB, patch)
2022-09-16 06:21 PDT, alan 		no flags
DetailsFormatted DiffDiff
[fast-cq]Patch (11.17 KB, patch)
2022-09-16 08:57 PDT, alan 		no flags
DetailsFormatted DiffDiff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1 2022-09-14 17:39:16 PDT
<rdar://problem/99945248>
alan
Comment 2 2022-09-15 20:47:50 PDT
in InlineContentBuilder::createDisplayLines, we seem to mix logical and physical overflow values. childScrollableOverflow needs a logical -> physical translation before calling unite diff --git a/Source/WebCore/layout/integration/inline/LayoutIntegrationInlineContentBuilder.cpp b/Source/WebCore/layout/integration/inline/LayoutIntegrationInlineContentBuilder.cpp index 8f228449b3c8..2be2a1c03d4c 100644 --- a/Source/WebCore/layout/integration/inline/LayoutIntegrationInlineContentBuilder.cpp +++ b/Source/WebCore/layout/integration/inline/LayoutIntegrationInlineContentBuilder.cpp @@ -129,7 +129,7 @@ void InlineContentBuilder::createDisplayLines(Layout::InlineFormattingState& inl childInkOverflow.move(box.left(), box.top()); lineInkOverflowRect.unite(childInkOverflow); } - auto childScrollableOverflow = renderer.logicalLayoutOverflowRectForPropagation(&renderer.parent()->style()); + auto childScrollableOverflow = renderer.layoutOverflowRectForPropagation(&renderer.parent()->style()); childScrollableOverflow.move(box.left(), box.top()); scrollableOverflowRect.unite(childScrollableOverflow); }
alan
Comment 3 2022-09-16 06:21:56 PDT
Created attachment 462392 [details] Patch
alan
Comment 4 2022-09-16 08:57:36 PDT
Created attachment 462395 [details] [fast-cq]Patch
EWS
Comment 5 2022-09-16 13:10:22 PDT
Committed 254569@main (ec6b5337e777): <https://commits.webkit.org/254569@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 462395 [details].
alan
Comment 6 2022-09-16 13:19:52 PDT
(In reply to Takao Baba from comment #0) > Created attachment 462330 [details] > testcase > > Steps to reproduce: > * Open attached testcase.html by Safari on iOS 16 in portrait mode. > > Expected behavior: > * Horizontal overflow won't happen. The <h1> content is the device width > (such as "980" for iPhone 13 Pro Max). > > Actual Behavior: > * On iOS 16, the root element causes overflow. The <h1> will be over 3000. > > Environment: > This looks a regression on iOS 16. iOS 15.6 works good. > > Note: > The logical height (physical width) of the root element seems include the > physical height of the inline-block element. The direction is opposite. Thank you for filing this bug (and thanks for the simple test case)!
Note You need to log in before you can comment on or make changes to this bug.