[wpt-sync] Sync PR 32979 - Avoid ComputeBlockSizeForFragment() on table sections / rows.
Categories
(Core :: Layout: Tables, task, P4)
Tracking
()
Tracking | Status | |
---|---|---|
firefox100 | --- | fixed |
People
(Reporter: wpt-sync, Unassigned)
References
()
Details
(Whiteboard: [wptsync downstream])
Sync web-platform-tests PR 32979 into mozilla-central (this bug is closed when the sync is complete).
PR: https://github.com/web-platform-tests/wpt/pull/32979
Details from upstream follow.
Morten Stenshorne <mstensho@chromium.org> wrote:
Avoid ComputeBlockSizeForFragment() on table sections / rows.
We used to do this in NGSimplifiedLayoutAlgorithm (but ignored the
result). ComputeBlockSizeForFragment() isn't called by the respective
row / section layout algorithms, so let's refrain from doing that in the
simplified layout algorithm as well. The problem was that no intrinsic
block-size is stored in the layout result for rows and sections, and
we'd fail a DCHECK in ResolveBlockLengthInternal(), since we were
passing an intrinsic block-size (0) less than border+padding.Note that this CL will also skip ComputeBlockSizeForFragment() for table
containers. It should be harmless to keep that, but since we're ignoring
the resulting block-size for tables as well, it seemed reasonable
(rather than making the debug code look silly).This is a speculative fix for crbug.com/1289408
Bug: 1289408
Change-Id: Ic817c67342891cd774e335c7560be2dfe915fb8d
Reviewed-on: https://chromium-review.googlesource.com/3487914
WPT-Export-Revision: 2a9a7a24b17ce242cb678c1d0c7bf6c1355f76d1
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 1•3 years ago
|
||
Assignee | ||
Comment 2•3 years ago
|
||
Assignee | ||
Comment 3•3 years ago
|
||
CI Results
Ran 0 Firefox configurations based on mozilla-central, and Firefox, Chrome, and Safari on GitHub CI
Total 1 tests
Status Summary
Firefox
PASS: 1
Chrome
PASS: 1
Safari
PASS: 1
Links
Comment 5•3 years ago
|
||
bugherder |
Description
•