Open Bug 1666797 Opened 2 months ago Updated 2 months ago

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

Categories

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

defect

Tracking

()

People

(Reporter: jwatt, Unassigned)

References

()

Details

(Keywords: testcase)

Attachments

(2 files)

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…

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

Thanks. That does indeed seem much more relevant.

Summary: Printing gets chopped off after first page on Kanji page → Printing gets chopped off after first page on website using flexbox

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.

Component: Printing: Setup → Layout: Flexbox
Depends on: 1640197
Keywords: testcase
OS: Unspecified → All
Hardware: Unspecified → All
Summary: Printing gets chopped off after first page on website using flexbox → [fragmentation] Printing gets chopped off after first page when using vertical writing-mode 'flex-direction: column' flexbox
Attached file Testcase #1

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?

Flags: needinfo?(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

Flags: needinfo?(ekaunt)

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.)

Flags: needinfo?(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

Flags: needinfo?(ekaunt)

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.

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.)

You need to log in before you can comment on or make changes to this bug.