Bug 1852515 Comment 8 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Here's a testcase that's a variant of the original, except with one additional grid item added in the first row (which happens to be end-aligned), and with a border around the grid.


This variant renders awkwardly in all engines I tested, in similar ways and for similar reasons as discussed above.   (Though for WebKit I only saw issues in a slightly-older WebKit-based browser; Safari 17 i.e. recent WebKit might be fine on this particular testcase at least)

Details on the various failure modes here:
* **Chrome**: prints an essentially-blank first page (they draw the grid border but no grid content), and they inexplicably have a bunch of blank space on the 3rd page, and the end-aligned item isn't end-aligned at all.  They do this even if I remove the `Some content` that precedes the grid.
* **Firefox**: prints a mostly-blank first page, for reasons discussed above (though we don't if you remove "Some content".  We also potentially slice text that straddles the pagebreak, as discussed in bug 1759926 comment 0 (as part of "slicing the element’s graphical representation"), though hopefully we can mitigate that at some point.
* **WebKit** never prints a blank page -- though at least in Epiphany aka gnome-web (a WebKit snapshot on Linux, specifically the version in available in 22.04), they push the last line of text down off of page 1 and onto page 2 to "dodge" having to slice at the pagebreak, and that results in text inadvertently overlapping or just looking awkwardly-close (depending on font/font-size) at the top of page 2.  (I can reproduce that in Epiphany on Linux, but not on Safari 17, so it's possible that the WebKit folks have fixed that recently; or maybe I'm not trying hard enough to make it happen in Safari 17.)
Here's a testcase that's a variant of the original, except with one additional grid item added in the first row (which happens to be end-aligned), and with a border around the grid.


This variant renders awkwardly in all engines I tested, in similar ways and for similar reasons as discussed above.   (Though for WebKit I only saw issues in a slightly-older WebKit-based browser; Safari 17 i.e. recent WebKit might be fine on this particular testcase at least)

Details on the various failure modes here:
* **Chrome**: prints an essentially-blank first page (they draw the grid border but no grid content), and they inexplicably have a bunch of blank space on the 3rd page, and the end-aligned item isn't end-aligned at all.  They do this even if I remove the `Some content` that precedes the grid.
* **Firefox**: prints a mostly-blank first page, for reasons discussed above (though we don't if you remove "Some content".  We also potentially slice text that straddles the pagebreak, as discussed in bug 1759926 comment 0 (as part of "slicing the element’s graphical representation"), though hopefully we can mitigate that at some point.
* **WebKit** never prints a blank page -- though at least in Epiphany aka gnome-web (a WebKit snapshot on Linux, specifically the version available in Ubuntu 22.04), they push the last line of text down off of page 1 and onto page 2 to "dodge" having to slice at the pagebreak, and that results in text inadvertently overlapping or just looking awkwardly-close (depending on font/font-size) at the top of page 2.  (I can reproduce that in Epiphany on Linux, but not on Safari 17, so it's possible that the WebKit folks have fixed that recently; or maybe I'm not trying hard enough to make it happen in Safari 17.)
Here's a testcase that's a variant of the original, except with one additional grid item added in the first row (which happens to be end-aligned), and with a border around the grid.


This variant renders awkwardly in all engines I tested, in similar ways and for similar reasons as discussed above.   (Though for WebKit I only saw issues in a slightly-older WebKit-based browser; Safari 17 i.e. recent WebKit might be fine on this particular testcase at least)

Details on the various failure modes here:
* **Chrome**: prints an essentially-blank first page (they draw the grid border but no grid content), and they inexplicably have a bunch of blank space on the 3rd page, and the end-aligned item isn't end-aligned at all.  They do this even if I remove the `Some content` that precedes the grid.
* **Firefox**: prints a mostly-blank first page, for reasons discussed above (though we don't if you remove "Some content".  We also potentially slice text that straddles the pagebreak, as discussed in bug 1759926 comment 0 (as part of "slicing the element’s graphical representation"), though hopefully we can mitigate that at some point.
* **WebKit** never prints a blank page -- though at least in Epiphany aka gnome-web (a WebKit snapshot on Linux, specifically the up-to-date version currently available in Ubuntu 22.04), they push the last line of text down off of page 1 and onto page 2 to "dodge" having to slice at the pagebreak, and that results in text inadvertently overlapping or just looking awkwardly-close (depending on font/font-size) at the top of page 2.  (I can reproduce that in Epiphany on Linux, but not on Safari 17, so it's possible that the WebKit folks have fixed that recently; or maybe I'm not trying hard enough to make it happen in Safari 17.)

Back to Bug 1852515 Comment 8