1663079 - (park-wta) Forced page breaks inside flex items isn't handled correctly

Status: RESOLVED DUPLICATE of bug 1744363

(Core :: Layout: Flexbox, defect)

Description

[Jeff Walden [:Waldo]]

Park Tool has a Wheel Tension App you can use to properly tension a new or existing bicycle wheel. Pick the spoke material, shape, and thickness, set the number of spokes on each side of the wheel, then enter in Park Tool's TM-1 tensiometer readings and it'll tell you how close you've gotten your wheel to even tensions on both sides of the wheel. It offers the ability to annotate and save wheel settings to a URL that stays live for a year (after that you have to reenter your data to get another year).

The WTA lets you print your measurements -- partly for convenience, partly so you have a printout you can reenter when your year's up. In Firefox, the WTA displays the ominous warning:

Firefox Users: Printing from Firefox may not show all of the page data. If you have problems, try printing from another browser.

Gak.

---

When I print in Firefox, I see a few problems:

Input box widgets print funky on Linux

The input boxes for entering spoke thickness or wheel tension reading are numeric inputs with discrete spacing (the TM-1 is only accurate to half-steps). Firefox shows them as textboxes with up and down arrows to increase or decrease by 0.5, when you're just viewing the page normally.

These form elements, when printed under Linux, display blown-up/exploded but maybe clipped to the expected bounding box -- very weird-looking. (Chromium by contrast just prints the text, no visible form widgetry. [Chromium's up/down arrows only display in an input when the input is selected, it looks like. Printing may implicitly invoke the not-selected state.] It's not clear whether printing no form widgetry is a feature or bug.)

Ugly, more than a papercut, but not the biggest deal. Good chance there's already a bug on file for this.

The wheel summary tables print overlapping/underneath the wheel visualization

In Chromium the left/right wheel tables print side by side on the page, and immediately following them (chopped in two by a page boundary -- devtools say #wheel-chart-wrapper is page-break-before: always;, so that's probably a Chrome bug) is the wheel visualization. After that follows the wheel summary tables displaying each wheel's average tension/standard deviation/etc.

In Firefox, the left/right wheel tables aren't side-by-side -- perhaps a font difference, not necessarily a bug, I didn't investigate. (Also there's some font coloring differences, again not sure why, maybe not a bug, could be a side effect of how we alter text coloring when printing without background colors/images.)

The big problem is that not even immediately after the right side spokes table ends, the wheel summary tables start -- the two even overlap! And the wheel visualization should have appeared first, before the summary table. Instead, it's deferred to the start of the next page (there's not enough space on the page to print it), consistent with page-break-before: always;, but the summary table is not similarly moved downward to be after the visualization.

---

The form element thing looks ugly, but it's not a terribly big deal. Park Tool may not even know about it -- their YouTube videos suggest they could be a Mac shop.

But the visualization/summary table overlap bits are pretty bad, and they're likely the reason for the Firefox-specific print warning. Technically there's no dataloss -- the visualization and summary tables are byproducts of the wheel settings (near top of the first page) and the spoke tension readings (found in the charts, and readable even despite the prior glitches). But no mechanic wanting to record this sort of archival info wants Firefox's glitchy print output.

---

I've added a test URL to reproduce these printing problems, that should stay live for about a year. (I haven't attempted to save-as-complete or anything to check if such would replicate the problem. And I don't know what state of the art is for saving/rewriting a live webpage such that all this sort of thing checks out.) The WTA probably isn't going to change in ways that affect us, but ideally we extract a standalone testcase from the page sooner rather than later.

I know ~nil about printing, so I'm filing this as metabug, and hopefully people can figure out what the issues are here and tag appropriate dependencies.

Comment 1

[Jeff Walden [:Waldo]]

Attachment: Printing test wheel - Firefox.pdf

Comment 2

[Jeff Walden [:Waldo]]

Attachment: Printing test wheel - Chromium.pdf

Comment 3

[Cameron McCormack (:heycam)]

Removing the meta keyword so it shows up in our triage lists.

Comment 4

[Sean Voisen (:svoisen)]

We have similar, though not identical, form control printing issues reported for macOS in bug 1563528.

Comment 5

[Mats Palmgren (inactive)]

Attachment: Testcase #1

STR
Load this testcase in Print Preview and set the page size to A4.

ACTUAL RESULTS
The text "Item 1" is still on page 1 even though its container has page-break-before:always and the text "Item 2" is pushed to page 3 but its parent (a flex item) remains on page 2 and isn't split.

EXPECTED RESULTS
Chrome renders it correctly I think.

Comment 6

[Hani Yacoub, Desktop QA]

Steps from Comment 5 are still reproducible.

Comment 7

[Daniel Holbert [:dholbert]]

Note: the fix for related bug 1739561 doesn't seem to have changed our rendering of the attached testcase. We still print-preview it as-described in comment 5 (in Firefox release 101 as well as latest Firefox Nightly 103).

Comment 8

[Emily McDonough [:alaskanemily]]

Attachment: Testcase #2

I hit this while implementing CSS named-pages, included is a reduced testcase which shows the results being out-of-order.

Comment 9

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

After bug 1744363, forced breaks (e.g. break-after: page) inside flex item kind of works because flex item can grow its block-size, and that makes testcase #2 in comment 8 work as expected. But we haven't implement forced break propagation (bug 1772396) on block container, so break-before cannot propagate from the first line to block container yet. What is why testcase #1 doesn't have the correct output, but that is a block container issue, not a flexbox issue. I filed bug 1890238 to implement forced page breaks on flex items.

Comment 10

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Attachment: Firefox 126 - Wheel Tension App Park Tool.pdf

I test https://www.parktool.com/wta/ again on Firefox Nightly, and the print output looks good. I don't see any content overlap. I guess it is because the sites has an workaround or we've improved the flexbox printing over these years, so I incline to make this a dup of bug 1744363.

We can fix testcase #1 in bug 1772396 and make further forced break improvements for flex item in bug 1890238.