1187457 - Various issues with absolutely positioned elements in paged media, when they end up on a different page than their containing block

Status: NEW

(Core :: Layout, defect)

Description

[Julien Wajsberg [:julienw]]

STR:
1. Open one of the testcases.
2. Open Print Preview from the "File" menu.
3. Take care that the orientation is set to "Portrait" and "100%".
4. Observe the absolutely positioned element. It's either badly positioned or not shown at all.

Comment 1

[Julien Wajsberg [:julienw]]

Attachment: testcase-print.html

In this testcase, the codes at the bottom (the "dt" part) are absolutely positioned without top/left/right/bottom/width/height specified. In print preview they end up in in the same location on the first page instead of in different locations on the second page.

When I set "position: relative" on the closest containing block that is only on the second page then it works fine.

The same happens when printing in a PDF (which is my use case).

Comment 2

[Julien Wajsberg [:julienw]]

Attachment: testcase-print2.html

This testcase is simpler. The text at the end is absolutely positioned in the same way (without top/left/right/bottom/width/height) and the same happens.

Comment 3

[Julien Wajsberg [:julienw]]

Attachment: testcase-print3.html

This testcase is similar to the second one, except we specify "top". As a result it's not displayed at all in the print result.

Comment 4

[Julien Wajsberg [:julienw]]

From [1]:

In paged media, an absolutely positioned element is positioned relative to its containing block ignoring any page breaks (as if the document were continuous). The element may subsequently be broken over several pages.

For absolutely positioned content that resolves to a position on a page other than the page being laid out (the current page), or resolves to a position on the current page which has already been rendered for printing, printers may place the content

-  on another location on the current page,
-  on a subsequent page, or
-  may omit it. 

[1] https://drafts.csswg.org/css2/visudet.html#containing-block-details


While the 3rd testcase could be the 3rd case as specified above, I believe the 1st and 2nd testcases are not falling in any of the cases.

For sure the printing output is really different to the browser output.

Comment 5

[Julien Wajsberg [:julienw]]

The problem with the "position: relative on a closer ancestor" solution is that if this ancestor itself is split between pages we end up with the same issue.

Comment 6

[Julien Wajsberg [:julienw]]

Attachment: testcase-print4.html

See for example this testcase.

Comment 7

[Julien Wajsberg [:julienw]]

Attachment: testcase-print4.pdf

and its pdf rendering.

Comment 8

[Julien Wajsberg [:julienw]]

FWIW Chromium does not seem to have the issue (tested in Chromium 43).

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Is some of this duplicate of bug 166836, bug 179135, bug 267029, or some of the issues that I believe were supposed to have been filed (and may or may not have been) as followups of bug 154892?

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(Fundamentally, we probably need to reflow absolutely positioned elements after all of the fragments of their containing block have been reflowed, which may mean placing them on a page that we thought was complete.  I'm not sure if there are any bugs that reflect the work that we need to do architecturally rather than cases that are currently broken, although I thought such bugs were filed at one point...)

Comment 11

[Julien Wajsberg [:julienw]]

I'd say cases 1, 2, 4 are bug 179135, and case 3 may be bug 267029.

But note that case 4 is somewhat different: the relatively positioned ancestor makes that the absolutely positioned element stays in this ancestor.