1956112 - abspos content with "bottom:0" (or "bottom:<anything>") ends up on first page when printed/print-previewed, despite its containing block being multiple pages tall

Status: RESOLVED DUPLICATE of bug 2002115

(Core :: Printing: Output, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

STR:

1. Print-preview the attached testcase. (Ideally using US Letter or A4 sized page)

ACTUAL RESULTS:
All of the dashed-border abspos elements end up on page 1 (except for the "beyond end of document" one)
In particular, the "CAN YOU SEE ME" element cannot be seen (because it's been pushed off the top of page 1), and the "SHOULD ALIGN WITH BOTTOM BORDER" element is instead aligned with the bottom of page 1.

EXPECTED RESULTS:
Dashed-border abspos elements' should be placed at their requested offsets, relative to the end of the solid black border.
In particular:

• the "CAN YOU SEE ME" element should be visible on page 1 (since its offset pushes it most of the way but not entirely off the top of the 16in-tall black-bordered area)
• the "SHOULD ALIGN WITH BOTTOM BORDER" element should be at the very end of the black-bordered area (with the dashed border just inside with the black border).

Safari 18.3.1 gives EXPECTED RESULTS.
Chrome 135 gives EXPECTED RESULTS (with one minor bug - they superimpose the gray border on top of the black border instead of being snug up against it).
Firefox Nightly 138 gives ACTUAL RESULTS.

I suspect this is complex to fix... It's been a while since I looked at abspos fragmentation in depth, but I think in at least some cases, we put all abspos elements in the first continuation of their abspos containing block, or something along those lines? At least, that's what seems to be happening here. And then we use that first-continuation as the abspos top/botto/etc. constraint area, and so that's why we're resolving bottom:0 to the bottom of the first page.

I could imagine us always pushing such elements to the next continuation for bottom:0, but it likely gets tricky to handle if we're not sure if the abspos will fit between the top of the next page and the end of the containing block, and in particular it's probably tricky if the bottom value itself might end up pushing us back upwards partly or entirely onto the previous page.

Comment 1

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

This bug is fixed when layout.abspos.fragmentainer-aware-positioning.enabled=true, because bottom:<some value> is computed in a printing measuring reflow. I'm marking this a duplicate of bug 2002115.

Daniel, let me know if I missed anything.