1848431 - abspos content that's intended for the top of page 2 gets instead placed at the bottom of page 1 and then overflows onto page 2 (or is clipped, if inside `overflow:hidden`)

Status: NEW

(Core :: Printing: Output, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

[I'm spinning this off from bug 1816345, to cover the issues shown by the testcases that I posted there in bug 1816345 comment 9 and 10. Fixing this bug here would help with fixing that bug, but I think we can address 1816345 in other ways too; hence this spin-off.]

STR:

1. Print-preview the attached testcase.

ACTUAL RESULTS:
The abspos content for the second page is broken. Its first line (You should see this) gets painted at the top of page 2, overlapping its second line (full sentence appear on).

EXPECTED RESULTS:
No such overlap. The layout on page 2 should look like the layout on page 1.

What happens is we attempt to reflow the second fullpage-containing-block at the bottom of page 1 (when we're down to having zero available height), and it decides that its first child (a zero-height placeholder) fits there. So we place a single line of the abspos frame at the very bottom of the first page (overflowing off the bottom), and it gets a continuation at the top of page 2.

Then the fragmentation fallback lets us paint the overflowing abspos from page 1 at the top of page 2. That's nice but still not-great. (Also, if you uncomment overflow:hidden in the testcase, then that overflowing content just gets clipped instead, so you don't see the second page's first sentence at all.)

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (using 'overflow:hidden')

For convenience, here's a testcase where we have overflow:hidden enabled on the page wrapper. This makes the first few words intended for page 2 end up being clipped entirely.

Comment 2

[Daniel Holbert [:dholbert]]

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

(Also, if you uncomment overflow:hidden in the testcase, then that overflowing content just gets clipped instead, so you don't see the second page's first sentence at all.)

This^ part (demonstrated by testcase 2 here) is likely a version of bug 1856081 which I spun off.

Let's focus this bug here on the overlapping-text shown in testcase 1.

Comment 3

[Jonathan Watt [:jwatt]]

Attachment: Another testcase with no position:relative container

Another testcase that exhibits similar behavior. Interestingly, in this case the top border is placed on the previous page, then the rest of the div is painted on the following page.

Comment 4

[Jonathan Watt [:jwatt]]

https://phabricator.services.mozilla.com/D186061 added code that looks like it might deal with this to nsBlockFrame::ReflowBlockFrame to call PushTruncatedLine() and return early. In the case of the testcase that I just added (I haven't checked the others yet), that code isn't hit when we reflow the nsPlaceholderFrame though. That's because aLine->IsBlock() returns false in nsBlockFrame::ReflowLine, so it calls ReflowInlineFrames() instead of ReflowBlockFrame().

I've tried doing the PushTruncatedLine() thing in ReflowInlineFrames, the function it calls, DoReflowInlineFrames, and in the function that calls, ReflowInlineFrame. All I seem to be able to achieve though is either causing the entire div to paint on the first page, or else a crash. I should say I don't really know what I'm doing in this code, so someone who knows it better may have better luck.

Comment 5

[Jonathan Watt [:jwatt]]

This bug does not affect Gdocs.