Bugzilla

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

(Before our current approach, these would 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.

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 )

(Before our current approach, these would 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.

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 approach, these would 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.

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.