2003692 - Vertically-centered abspos element in tall container (spanning multiple pages/fragments) gets centered in just the first fragment

Status: RESOLVED DUPLICATE of bug 2002115

(Core :: Layout: Positioned, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Filing this bug for a scenario that came up in discussion with TYLin -- this is a document with a 6-pages-tall fixed-height div, which serves as a container for an absolutely-positioned child that's centered using auto margins. Chrome centers the abspos element in the full fragmented container (placing the element at the boundary between page 3 and 4), which I think is correct. Firefox centers the abspos element in the first fragment.

STR:

1. Print-preview the attached testcase.
2. Scroll through the preview to find the "AAA/BBB/CCC" text.

EXPECTED RESULTS:
AAA/BBB/CCC should be centered within the solid-bordered container, i.e. straddling the boundary between page 3 and page 4 (with "BBB" pushed to page 4 to avoid being sliced down the middle)

ACTUAL RESULTS:
AAA/BBB/CCC are centered on the first page.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: screenshot showing the bug (Firefox on left, Chrome on the right)

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (same as 1 but now the container is auto-height)

Here's a testcase where I've made things a bit trickier-to-get-correct by making the containing block have an automatic height (derived from its in-flow contents, which happen to still be tall).

In testcase 1, you could imagine us doing an up-front placement of the abspos element based on knowing the container's height. But in this more-general case, we don't know the container's height up front (particularly if you imagine the tall child being e.g. paragraphs of text rather than a fixed-height div). Here, we're unable to compute the correct centered position for the abspos element until we've actually laid out all the in-flow children, and we've found how tall the container really is.

Chrome handles this case properly.

Comment 3

[Daniel Holbert [:dholbert]]

To handle testcase 2 properly, we probably have to do something like:

1. ignore the abspos container's children entirely (e.g. just stash them on the abspos-container's first-in-flow) until we reflow the abspos-container's final continuation (the continuation that reports itself as either "complete" or "overflow-incomplete")
2. At that point, that final continuation would then need to kick off a "second pass", from its first-in-flow, to reflow the abspos children (which are presumably still stashed on the first-in-flow).
3. That second-pass would have full knowledge of the in-flow heights of the container's fragments, so it can figure out the proper centered position[i] of abspos children, and resolve percent heights, and things like that, to figure out which fragment they should be placed on & at what offset, and lay them out (and potentially fragment them).
4. This may also end up being recursive - e.g. an abpsos element (reflowed in this "second pass") might itself span multiple pages and have children inside of it, which would need to get reflowed in a "second pass" (while we're inside of an outer "second pass").

[i] TYLin correctly observed that, to compute the vertically-centered position of an abspos child, we'll need to know that abspos child's "un-fragmented" block-size -- so presumably we'd have to reflow it with unconstrained available-bsize to give us a bsize-measurement that we can vertically center (or place at a particular offset from the end of the document for bottom: Npx etc); and then we'd place it at whatever properly-aligned position that we arrive at, given that bsize-measurement (in some possibly-in-the-middle fragment); and then we'd give it another reflow with the actual available-bsize so that it can properly fragment (as-needed) and lay out all of its contents, as the "AAA"/"BBB"/"CCC" does in my testcases in chrome.)

Comment 4

[Ting-Yu Lin [:TYLin] (PST, UTC-7)]

After bug 2002115, we render both testcase 1 and 2 the same as Google Chrome. I'm marking this a dup.