Open Bug 1663079 (park-wta) Opened 1 year ago Updated 4 months ago

Forced page breaks inside flex items isn't handled correctly

Categories

(Core :: Layout: Flexbox, defect)

defect

Tracking

()

Tracking Status
firefox89 --- affected
firefox90 --- affected
firefox91 --- affected

People

(Reporter: Waldo, Unassigned)

References

(Blocks 2 open bugs, )

Details

(Keywords: testcase)

Attachments

(3 files)

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.

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

Keywords: meta
Alias: park-wta

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

Attached file 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.

Component: Printing: Output → Layout: Flexbox
Keywords: testcase
OS: Unspecified → All
Hardware: Unspecified → All
Summary: Park Tool's WTA (wheel tension app) prints poorly → Forced page breaks inside flex items isn't handled correctly
Blocks: 939897

Steps from Comment 5 are still reproducible.

QA Whiteboard: qa-not-actionable
You need to log in before you can comment on or make changes to this bug.