1666797 - [fragmentation] Printing gets chopped off after first page when using vertical writing-mode 'flex-direction: column' flexbox

Status: RESOLVED INVALID

(Core :: Layout: Flexbox, defect, P3)

Description

[Jonathan Watt [:jwatt]]

From https://support.mozilla.org/en-US/questions/1304337

I'm trying to print this page (https://eecaunt.github.io/kanji-sakuin.html), but firefox only prints out the first page, then stops. (Here's a small test version of the same page: https://eecaunt.github.io/kanji-sakuin-small.html)

If you see weird overlapping text, then just reload the page. idk why firefox sometimes doesnt finish loading the page…

Comment 1

[ekaunt]

The main issue with this page is that its set up using flexbox (and not becaure its filled with kanji)

Comment 2

[Jonathan Watt [:jwatt]]

Thanks. That does indeed seem much more relevant.

Comment 3

[Mats Palmgren (inactive)]

There's only one page in Print Preview in Chrome too, fwiw.

I think our fallback strategy in bug 1640197 will fix pages like this quite nicely.

Comment 4

[Mats Palmgren (inactive)]

Attachment: Testcase #1

Comment 5

[Mats Palmgren (inactive)]

If you see weird overlapping text, then just reload the page. idk why firefox sometimes doesnt finish loading the page…

ekaunt, could you file a separate bug on that problem please, assuming it's reproducible?

Comment 6

[ekaunt]

(In reply to Mats Palmgren (:mats) from comment #5)

If you see weird overlapping text, then just reload the page. idk why firefox sometimes doesnt finish loading the page…

ekaunt, could you file a separate bug on that problem please, assuming it's reproducible?

It only sometimes does it (every couple page refreshes). no idea exactly when tho

Comment 7

[Mats Palmgren (inactive)]

OK, could you file a separate bug on that and attach a screenshot of the content that overlaps? Thanks!
(Layout/Flexbox is probably a good component for initial triage of that bug.)

Comment 8

[ekaunt]

I was able to print out this webpage in the end by moving writing-mode: vertical-rl; from body to #container and pressing then printing it in chromium

Comment 9

[Daniel Holbert [:dholbert]]

So there are a few issues that I see here, which makes this testcase difficult to fragment:

(1) The writing-mode on the body and the html elements disagree. We're trying to fragment the testcase in the block axis (so, we're fragmenting vertically, because we're following the writing-mode of the html element). But the vertical axis is actually the inline axis of the body element and its content, and we don't support fragmenting in the inline axis (other than just regular line-wrapping). So we don't fragment the content successfully.

(2) If you address that^ by e.g. adding html { writing-mode: vertical-rl }, this still doesn't really help, because the content still overflows vertically, because it's styled with a limited width and an unbounded height, and with flex-direction: column and flex-wrap: wrap. So the block axis is horizontal (right to left), BUT content doesn't actually stack very far in that direction -- when we hit the specified width, we wrap to another horizontal "flex column". This ends up meaning that adding more content increases the height (growing in the content's inline axis).

SO: if you set a writing-mode on the html element to address my point (1) above, this testcase ends up being effectively a vertical-writing-mode equivalent of a page like this one:
data:text/html,<div style="height:5in; width:30in; border: 5px dotted black">
...where we've just got a bunch of content that overflows in the inline axis, which we can only fit if the user picks "Fit to page width" as their scale option in our print settings. (And as far as I can tell, that "fit to page width" [really, inline-size] feature does indeed work here, if you do specify the writing-mode on the html element.)

If you don't set the writing-mode on the html element, then the content will overflow in the document's block direction, in which case Mats is correct that bug 1640197 should help.

Comment 10

[Mats Palmgren (inactive)]

Attachment: Alternative layout to avoid this bug

An alternative layout might be to use a normal row flexbox with horizontal writing-mode and make all its items have vertical writing-mode instead, like this. Our flexbox fragmentation supports this case since it's now fragmenting in its block-axis between flex lines. This will actually give a better fragmentation result since it will break between flex lines and thus not slice the items between two pages. (This makes the flexbox layout its items from left-to-right though. I'm not sure if that's desirable or not in this case. So perhaps add direction: rtl on the container and direction: ltr on the items too.)

Comment 11

[Thomas Wisniewski [:twisniewski]]

This is also affecting print-outs of pages at seekingalpha.com (although not in the print preview, only the actual print-outs).

Comment 12

[Dennis Schubert [:denschub]]

We no longer have site breakage affected by this - both reports now work. Testcase #1 also appears to work consistently on both browsers: the lower part gets cut off in both Chrome and Firefox. But given comment 4, this issue looks a bit more complicated, so I'll just remove the WebCompat priority here.

Comment 13

[Daniel Holbert [:dholbert]]

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

If you don't set the writing-mode on the html element, then the content will overflow in the document's block direction, in which case Mats is correct that bug 1640197 should help.

This turned out not to be true for some reason, though I'm not entirely sure why.

Comment 14

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (html with horizontal WM, body with vertical WM, div with tall height)

Comment 15

[Daniel Holbert [:dholbert]]

Attachment: testcase 3 (html/body with horizontal WM, div with vertical WM, div with tall height)

Here's a testcase where I've moved the vertical WM one step downwards in the DOM, to a div wrapper-element. That behaves the way we expect (triggering the fragmentation fallback and producing multiple pages as long as layout.display-list.improve-fragmentation is enabled).

Comment 16

[Daniel Holbert [:dholbert]]

I suspect there's a special behavior for orthogonal writing-mode on the body vs. html element (for testcase 2) in printing -- it seems to be interoperable at least, since Firefox, Chrome, and Safari all produce only one page of output for testcase 2, vs. three pages of output for testcase 3.

The original site (linked in comment 0) only produces 1 page of output in Firefox, WebKit, and Chrome, for that same reason that testcase 2 does (since the original site is essentially a more-complex version of testcase 2). (Chrome and to-a-lesser-extent WebKit also have a substantial hang before they arrive at showing you that 1 page of output in their print-preview dialog.)

So: bottom line, I don't think there's a Firefox bug to fix or a clear interop issue to address here. Essentially: the site in comment 0 isn't really printable in the way that it intuitively looks like it would be, and that's because of its nested orthogonal writing-modes with content flowing off the bottom (inline edge) of a vertical writing-mode element (the side where fragmentation does not happen, equivalent to extremely wide content running off the right or left side of the page in a traditional horizontal-writing-mode document).

If someone wanted to write a site like the one in comment 0, and they want it to be printable with the content being split vertically across pages, they would need to write their HTML/CSS using a horizontal writing-mode (to get vertical page-splitting) from the root element down-to-and-inlcuding the element that's expecting to be vertically split (the tall flex container). Inside of that, the content could specify writing-mode:vertical-rl for the actual text containers inside of each page; but a vertical writing mode spanning multiple pages is not really going to work, if the content is overflowing vertically.

(See also bug 1806717 for known issues with printing column-oriented wrappable flex containers, which may come into play in certain variants of this site too. But that's not really related to the core/proximal issue that this site is running up against.)