1831201 - In print & print-preview, a negative margin-top/margin-bottom that shifts content upwards off the top of a page will cause that content to be clipped/missing, instead of placed on previous page

Status: NEW

(Core :: Printing: Output, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

STR:

1. Print-preview the attached testcase (which has a large negative margin-bottom on the tall bordered element)

ACTUAL RESULTS:
The Text after the header -- can you see [...] text is not present anywhere in the print previewed output. The numbered list starts at the top of page 2 and the first 30+ list items are missing, apparently shifted off the top of the page into oblivion.

EXPECTED RESULTS:
The text & list items should all be visible (shifted upwards onto the first page).

This is apparently causing some trouble when print-previewing certain cnn.com pages, as discussed in bug 1830307.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: testcase 2

Here's a testcase where the thing with a negative margin-bottom is itself on page 2, but its margin is sufficiently negative to pull the following content back to render on page 1.

That content (This box should be near the bottom of page 1) doesn't render at all, when you print-preview this page in Firefox.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: testcase 3: now with negative margin-top

Here's another example, now with text shifting with negative margin-top. This is also broken.

(If I modify this testcase such that the first element has height: 100vh so that the negative-margin-top element is flush with the top of the second page, then it renders properly; but I suspect that's just because we parent it inside the first page's subtree before we fragment that first page, since it "fits" due to having a negative margin-box height.)

Comment 3

[Daniel Holbert [:dholbert]]

This has been an issue for quite a long time; I can reproduce the same ACTUAL RESULTS with all 3 testcases in Nightly 2015-01-01, version 37.0a1. (In that build, in order to test, I had to do File|New Non-e10s window so that print preview would work, and I needed to manually reduce the 100vh height a little bit in testcases 2 and 3 in order to hit the appropriate size, since we used to resolve that length to be a bit larger for some reason.)

Hence: triaging as S3, given that this is a longstanding bug.

Comment 4

[Daniel Holbert [:dholbert]]

Assuming the frames are shifted off the top of the page, one approach here might be to use the codepath that's guarded by layout.display-list.improve-fragmentation. I think this problem-space (one page needing to draw content that overflowed off of another page) is similar in theory to what that code is trying to achieve.

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #0)

This is apparently causing some trouble when print-previewing certain cnn.com pages, as discussed in bug 1830307.

Note, we've mitigated this issue at CNN in particular using a WebCompat intervention (bug 1836105).