Consider the following testcase:
<!DOCTYPE HTML>
<style>
body { font-size: 32pt; margin:0; }
</style>
<div style="color:blue">
<div style="position:absolute; top:calc(100% - 20px); border:1px solid">Hello</div>
<div style="break-after:always">1</div>
<div style="">2</div>
</div>In Print Preview you would get something like:
because of bug 267029.
I have an idea of how to fix bugs like this where we don't fragment a frame for some reason and it instead overflows the page content area and we clip it with "dataloss". This can be fixed in a general way by building a DisplayList for the frames on the first page with a clip area that corresponds to the second page (i.e. that starts exactly at the end edge of the first page and has the size of the second page) and include that in the DisplayList for the second page. Then you get the desired result:
I hacked up a proof-of-concept for the above using the same technique as we use here: https://searchfox.org/mozilla-central/rev/446160560bf32ebf4cb7c4e25d7386ee22667255/layout/generic/nsPageFrame.cpp#515-543
My DisplayList-fu is weak though, so I'm hoping that someone on the Web Painting team can investigate this idea further...
This would "fix" most of the high priority bugs we have on our list of bugs here. We still want to fix some of those properly of course, by improving the fragmentation, but the fallback mechanism described above would work as a pretty good interim solution (in most cases on par with other UAs). Also, it's pretty much exactly what the spec calls for in the remaining cases where we can't find a break opportunity for some reason. It says:
(my emphasis)