Bug 238643 - Implement support for aligning baselines through subgrids
Summary: Implement support for aligning baselines through subgrids
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Matt Woodrow
URL:
Keywords: InRadar
Depends on:
Blocks: 236959
  Show dependency treegraph
 
Reported: 2022-03-31 18:03 PDT by Matt Woodrow
Modified: 2022-04-18 14:45 PDT (History)
16 users (show)

See Also:


Attachments
Patch (17.14 KB, patch)
2022-03-31 18:16 PDT, Matt Woodrow
no flags Details | Formatted Diff | Diff
Patch (34.42 KB, patch)
2022-04-06 02:35 PDT, Matt Woodrow
no flags Details | Formatted Diff | Diff
Patch (34.54 KB, patch)
2022-04-06 13:38 PDT, Matt Woodrow
no flags Details | Formatted Diff | Diff
Patch (34.51 KB, patch)
2022-04-13 21:18 PDT, Matt Woodrow
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Matt Woodrow 2022-03-31 18:03:23 PDT
We should recurse into subgrids when looking for items to contribute to a baseline sharing group.
Comment 1 Radar WebKit Bug Importer 2022-03-31 18:10:46 PDT
<rdar://problem/91138101>
Comment 2 Matt Woodrow 2022-03-31 18:16:46 PDT
Created attachment 456302 [details]
Patch
Comment 3 EWS Watchlist 2022-03-31 18:18:37 PDT
This patch modifies the imported WPT tests. Please ensure that any changes on the tests (not coming from a WPT import) are exported to WPT. Please see https://trac.webkit.org/wiki/WPTExportProcess
Comment 4 Matt Woodrow 2022-04-06 02:35:24 PDT
Created attachment 456795 [details]
Patch
Comment 5 Matt Woodrow 2022-04-06 13:38:28 PDT
Created attachment 456856 [details]
Patch
Comment 6 Javier Fernandez 2022-04-08 02:40:58 PDT
Comment on attachment 456856 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=456856&action=review

The change looks good, but I'd like to understand better why some ASSERTs has been removed.

> Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:-923
> -    ASSERT(!child.needsLayout());

Why this ASSERT is removed ?

> Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:-948
> -    ASSERT(m_renderGrid->isBaselineAlignmentForChild(item, axis));

Why this ASSERT has been removed ?
Comment 7 Matt Woodrow 2022-04-11 20:47:19 PDT
Comment on attachment 456856 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=456856&action=review

>> Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:-923
>> -    ASSERT(!child.needsLayout());
> 
> Why this ASSERT is removed ?

We only require the child to have completed layout if we are going to synthesise a baseline.

I moved this assertion to two places within GridBaselineAlignment so that it only gets checked when we attempt to synthesise a baseline (and means we can align subgrid children that haven't been laid out yet, as long as they have a real baseline).

>> Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:-948
>> -    ASSERT(m_renderGrid->isBaselineAlignmentForChild(item, axis));
> 
> Why this ASSERT has been removed ?

m_renderGrid is the outermost grid, and isBaselineAlignmentForChild is only guaranteed to return true on the parent grid of item.

I could change this to ASSERT(downcast<RenderGrid>(item.parent())->isBaselineAlignmentForChild(item, axis));, but since the only callers of this function also check that, it didn't seem necessary.
Comment 8 Javier Fernandez 2022-04-13 10:45:04 PDT
Comment on attachment 456856 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=456856&action=review

>>> Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:-948
>>> -    ASSERT(m_renderGrid->isBaselineAlignmentForChild(item, axis));
>> 
>> Why this ASSERT has been removed ?
> 
> m_renderGrid is the outermost grid, and isBaselineAlignmentForChild is only guaranteed to return true on the parent grid of item.
> 
> I could change this to ASSERT(downcast<RenderGrid>(item.parent())->isBaselineAlignmentForChild(item, axis));, but since the only callers of this function also check that, it didn't seem necessary.

If I remember correctly, this assert was added to detect outdated elements in the cache, which might be target of a style change that could affect to the align-self or justify-self properties. Theoretically, we call cacheBaselineAlignedItem only if the items have baseline as value for theses properties, hence the ASSERT (eg, RenderGrid::computeIntrinsicLogicalWidths)
Comment 9 Matt Woodrow 2022-04-13 21:18:45 PDT
Created attachment 457591 [details]
Patch
Comment 10 Matt Woodrow 2022-04-13 21:19:21 PDT
(In reply to Javier Fernandez from comment #8)
> Comment on attachment 456856 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=456856&action=review
> 
> >>> Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:-948
> >>> -    ASSERT(m_renderGrid->isBaselineAlignmentForChild(item, axis));
> >> 
> >> Why this ASSERT has been removed ?
> > 
> > m_renderGrid is the outermost grid, and isBaselineAlignmentForChild is only guaranteed to return true on the parent grid of item.
> > 
> > I could change this to ASSERT(downcast<RenderGrid>(item.parent())->isBaselineAlignmentForChild(item, axis));, but since the only callers of this function also check that, it didn't seem necessary.
> 
> If I remember correctly, this assert was added to detect outdated elements
> in the cache, which might be target of a style change that could affect to
> the align-self or justify-self properties. Theoretically, we call
> cacheBaselineAlignedItem only if the items have baseline as value for theses
> properties, hence the ASSERT (eg, RenderGrid::computeIntrinsicLogicalWidths)

Alright, I've added this check back.
Comment 11 Javier Fernandez 2022-04-18 09:45:28 PDT
Comment on attachment 457591 [details]
Patch

r=me
Comment 12 EWS 2022-04-18 14:45:18 PDT
Committed r292973 (249736@main): <https://commits.webkit.org/249736@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 457591 [details].