1759926 - fragmentation fallback can cause text to be sliced at pagebreaks, which is not-a-great experience

Status: NEW

(Core :: Printing: Output, defect, P3)

Description

[Daniel Holbert [:dholbert]]

As of bug 1681052, we have a "fallback" fragmentation codepath which "slices" certain classes of tall content that span multiple pages (rather than just having this content run off the page and be lost, as it used to be before we introduced that codepath, as described in e.g. bug 534182).

Strictly speaking, our slicing behavior is spec-compliant at least for display:inline-block and other inline-level container elements that we have to slice. Quoting the css-break-3 spec:

Since line boxes contain no possible break points, inline-block and inline-table boxes (and other inline-level display types that establish an independent formatting context) may also be considered monolithic: that is, in the cases where a single line box is too large to fit within its fragmentainer even by itself and the UA chooses to split the line box, it may fragment such boxes or it may treat them as monolithic.

https://www.w3.org/TR/css-break-3/

Also, a bit further along, the spec says (emphasis added):

[...] the UA may also fragment the contents of monolithic elements by slicing the element’s graphical representation.

https://www.w3.org/TR/css-break-3/#unforced-breaks

So: this slicing behavior is allowed by the CSS specs.

Nonetheless: it's unfortunate if this ends up slicing some text that a user cares about, particularly if other browsers don't slice that text. So, I suspect we'll accumulate bug reports about cases where text is sliced with this codepath. In some cases we can get sites fixed to avoid triggering the fragmentation-fallback (e.g. by removing inline-block styling on wrappers), but certainly we won't always be able to do that.

We may not be able to implement a real fix for this for a while, but we might be able to mitigate it somewhat, and we should at least track the fact that it's an issue. Hence, I'm filing this bug as a central place for that.

Comment 1

[Daniel Holbert [:dholbert]]

For the record, here's a list of containers which (when taller than a page) will cause us to trigger this "slicing" fragmentation-fallback behavior, which potentially results in slicing-text-in-half at pagebreaks:
(1) Elements with display: inline-block, inline-table, inline-grid, inline-flex.
(2) Tall grid rows (i.e. display:grid elements whose grid-template-rows property sets up a row that is itself taller than a page, either explicitly or due to being content-sized and having lots of content)

We treat these as "monolithic" and don't currently attempt to fragment them properly (i.e. by recursively asking descendants to find appropriate fragmentation points and to generate a tree like the one shown in https://wiki.mozilla.org/Gecko:Continuation_Model ). Instead, we use a slicing approach, as noted in comment 0.

(Before our current slicing approach, these containers [if extremely-tall] would all be clipped/lost at pagebreaks, per bug 534182 and bug 1417615, respectively)

When diagnosing a page that seems to have sliced text due to this issue, one investigatory technique is to use devtools to look upwards from the sliced element and try disabling CSS on ancestors that would make them into these sorts of containers.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: testcase 1: tall inline-block

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

For the record, here's a list of containers which (when taller than a page) will cause us to trigger this "slicing" fragmentation-fallback behavior, which potentially results in slicing-text-in-half at pagebreaks:
(1) Elements with display: inline-block, inline-table, inline-grid, inline-flex.

Here's a testcase for this category. As it turns out, Chrome actually slices text at pagebreaks for this category, just like Firefox does. (E.g. on my system, Chrome print-previews this testcase with some text split between page 1 and 2. That might vary depending on font / page size / etc, but if you scroll through the pages, you should see some pagebreak where text is split across pages, in both Chrome and Firefox.)

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: testcase 2: tall grid row

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

(2) Tall grid rows (i.e. display:grid elements whose grid-template-rows property sets up a row that is itself taller than a page, either explicitly or due to being content-sized and having lots of content)

Here's a testcase for this category. In this case, Chrome doesn't slice the text -- they seem to fragment properly and push a whole line of text to the next page. (Firefox does slice the text, just as in testcase 1.)

Given that this category (grids with tall rows), it's likely that we'll receive more interop bug reports for this category than for the first category (inline-block etc.), and it's possible we'll need to come up with a mitigation for this, i.e. an improvement to our grid layout code to handle this scenario better.