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