Closed Bug 1778097 Opened 2 years ago Closed 2 years ago

[wpt-sync] Sync PR 34704 - Handle specified table block-size correctly when fragmented.

Categories

(Core :: Layout, task, P4)

Product:
Core
Component:
Layout
Type:
task

Tracking

()

Status:
RESOLVED FIXED
Milestone:
104 Branch
Tracking Flags:
Tracking Status
firefox104 --- fixed

People

(Reporter: mozilla.org, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(Whiteboard: [wptsync downstream])

Sync web-platform-tests PR 34704 into mozilla-central (this bug is closed when the sync is complete).

PR: https://github.com/web-platform-tests/wpt/pull/34704
Details from upstream follow.

Morten Stenshorne <mstensho@chromium.org> wrote:

Handle specified table block-size correctly when fragmented.

Introduce table-specific break token data to make our job easier /
possible. The break token will know the total consumed block-size of the
"table box" (the table element, excluding captions), and also whether we
have entered the table box and whether we're also past it.

This involves some non-trivial changes to the table layout algorithm, so
that we can calculate the intrinsic block-size correctly (which
shouldn't be affected by the specified block-size), so that we can break
correctly inside the table. The fragmentation machinery will not break
inside if the intrinsic block-size is larger than available space,
except for the space taken up by block-end border/padding. The machinery
expects block-end border/padding to be included in the fragment size (it
will subtract it again, if necessary), even if we know we're going to
break inside. So we generally shouldn't omit block-end border/padding
when laying out the fragment. That's one thing less for the table layout
algorithm to worry about.

Had to shuffle some code around, so that we invoke the fragmentation
machinery before setting a table grid block-size.

I also discovered that we set the table column block-size incorrectly
when fragmented. Will address this in a follow-up CL, but added a TODO
for now.

Remove fragmentation/fragmented-table-with-fixed-height.html , since
it's invalid. It expects a table's specified height to be ignored if the
table gets fragmented, which is what the legacy fragmentation engine
does.

This also happens to fix crbug.com/1251689 , which is about a flexbox
with a table inside that establishes an orthogonal writing mode.
Probably fixed by the fact that we no longer let specified block-size
(and flex-basis, I suppose) affect the intrinsic block-size of the
table. The table layout algorithm has some hacks for intrinsic
block-size calculation when inside a flex container, which probably
didn't work in this particular case. Maybe we can remove that now.

Bug: 1335881, 1251689
Change-Id: I9a803daf5f08647aaa019ff0484e425406bc7d27
Reviewed-on: https://chromium-review.googlesource.com/3745936
WPT-Export-Revision: c7e137541e2195ebc006bdff2ab751d703d3975b

Component: web-platform-tests → Layout
Product: Testing → Core

CI Results

Ran 9 Firefox configurations based on mozilla-central, and Firefox, Chrome, and Safari on GitHub CI

Total 9 tests

Status Summary

Firefox

FAIL: 9

Chrome

PASS: 8
FAIL: 1

Safari

PASS: 8
FAIL: 1

Links

Gecko CI (Treeherder)
GitHub PR Head
GitHub PR Base

Details

Firefox-only Failures

New Tests That Don't Pass

Pushed by wptsync@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/3f505cf7a80d [wpt PR 34704] - Handle specified table block-size correctly when fragmented., a=testonly https://hg.mozilla.org/integration/autoland/rev/b2125abbebd2 [wpt PR 34704] - Update wpt metadata, a=testonly

https://hg.mozilla.org/mozilla-central/rev/3f505cf7a80d
https://hg.mozilla.org/mozilla-central/rev/b2125abbebd2

Status: NEW → RESOLVED
Closed: 2 years ago
status-firefox104: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 104 Branch
You need to log in before you can comment on or make changes to this bug.