1856081 - Tall monolithic abspos content doesn't render after the first page, if its containing block is `overflow:hidden` (even if it's multi-page)

Status: NEW

(Core :: Printing: Output, defect)

Description

[Daniel Holbert [:dholbert]]

I think this might be the same underlying issue as bug 1848431, but the testcase is different-enough that I want to spin it off.

(I also am more confident that the testcase here is similar to what's going on in bug 1853766.)

STR:

1. Print-preview the attached testcase.

EXPECTED RESULTS:
Purple border should extend onto the second page.

ACTUAL RESULTS:
No purple border is drawn on the second page.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: testcase 2

Just for completeness, here's a testcase where the abspos thing is taller and does actually eventually need to be clipped.

EXPECTED RESULTS:
Purple border should extend onto second page, all the way down to the bottom of the black-border (where it should be clipped).

ACTUAL RESULTS:
No purple border is drawn on the second page.

Comment 3

[Daniel Holbert [:dholbert]]

(Chrome gives EXPECTED RESULTS for both of these testcases.)

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: reference case 1

Here's a reference case for testcase 1.

I've simply removed position:absolute which makes us render it correctly for some reason.

Comment 5

[Daniel Holbert [:dholbert]]

Also/alternately: if you simply remove overflow:hidden from testcase 1, then we seem to render it correctly, too.

So: this bug seems to have something to do with overflow:hidden causing us to force clipping at the bottom edge of the containing-block-fragment that lives on page 1, in a way that is clipping abspos content (e.g. in testcase 1) but is not clipping in-flow content (e.g. in reference case 1), where this clipping is from the perspective of the fragmentation-fallback codepath, i.e. the layout.display-list.improve-fragmentation-controlled paint-my-overflow-on-the-next-page hackery.

Comment 6

[Jonathan Watt [:jwatt]]

This is already in the dependency tree of the gsuite bug, blocking bug 1853766.

Comment 7

[Jonathan Watt [:jwatt]]

This doesn't appear to affect Gdocs any more. I assume that's because Google has fixed up their code to use setProperty (working around bug 1865155 / bug 1867106), and as a result the absolutely positioned canvas element no longer overflows.

It does, however, still occur with the testcases, so this is still bug that should be fixed.

Comment 8

[Daniel Holbert [:dholbert]]

(In reply to Jonathan Watt [:jwatt] from comment #7)

This doesn't appear to affect Gdocs any more

It does still affect Gdocs via the STR in bug 1853766, at least. But I agree with your not-blocking assessment over there, as I just noted in a comment there.