When firefox pushes monolithic (i.e. unfragmentable) content to a new page and leaves behind a giant blank area, it's not a great experience (e.g. with tall grid row or inline-block)
Categories
(Core :: Printing: Output, defect)
Tracking
()
People
(Reporter: hywelj317, Unassigned)
References
(Depends on 1 open bug, Blocks 1 open bug)
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/117.0
Steps to reproduce:
-Create blank html page
-Add a long table in a container that is display: grid (That exceeds the end of the first printed page)
-Print page
Actual results:
-First page becomes blank, with the table now starting from the second page
-Adding page-break-before: avoid makes no difference
-Other browsers (Chrome & Edge) do not behave this way
Expected results:
-Table should remain on first page, spreading across other pages if needed
|
||
Comment 1•1 year ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Printing: Output' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 2•1 year ago
•
|
||
Yeah, this is a known issue, and it's kind-of intended behavior.
The underlying issue is that we don't properly support splitting a single grid-row across several pages -- we have a "slicing" approach which kinda-works but can e.g. cut lines of text in half, e.g. here
data:text/html,<!DOCTYPE html><body style="margin:0"><div style="display:grid"><div><div style="height:calc(100vh - 0.5em)">a</div>b</div>
(This testcase probably renders in print-preview with "b" split between page 1 and page 2 -- it does for me, anyway.)
I'm not sure if other browsers do anything much better, except perhaps by having heuristics to avoid slicing text in half -- we have bug 1759926 filed on doing that, at least.
Anyway -- we try to avoid the need to do these sorts of "slices" (or reduce how many we need) -- so if we encounter a grid-row that runs off of a page and will be sliced, and it's not already at the top of the page, then we push it to the next page so that it can draw more of its content before it needs to be sliced.
(We do this for other things that we fundamentally can't page-break "properly" as well -- e.g. display:inline-block)
|
|
||
Comment 3•1 year ago
|
||
--> Updating summary to generalize to the issue here, and adding bug 1759926 to see-also since it's another side of the same class of issue.
Maybe once we address bug 1759926 with heuristics, we can stop treating some of these containers as monolithic (i.e. unfragmentable), if the heuristics are reasonably good?
|
||
Comment 4•1 year ago
|
||
Just for the simplest case of mitigation, which should be fixed ASAP: The "split" should not force a page break if the page is new to start with
(ie- as per above, it should not force Page 1 to start on the second page of printing, nor should any subsequent page skip an output page if that page is new.)
|
|
||
Comment 5•1 year ago
•
|
||
That's how we already behave. If the unfragmentable thing is already at the top of a page, we don't push it to the next page.
In the testcase attached here, we push the grid row to page 2 because it's not at the top of its current page -- it's shifted down a little bit, due to the Some content div that's pushing it down. So, we push it to the next page since it'll fit (very slightly) better there. (Doesn't help much, but e.g. in a case where an unfragmentable thing is an image that's about a page tall, it may prevent us from unnecessarily slicing the bottom off of the image.)
If you edit the attached testcase to remove the Some content element (or give that element height:0), then we keep the grid on that first page, since then there is clearly no point in pushing it, as you note.
|
||
Comment 6•1 year ago
|
||
Grid is a presentational layout feature, its not a markup structure with a semantic meaning like a table. People will use this to lay out pages or page parts that will require printing. Deciding behaviour like this massively affects how it can be used. Whether that behaviour was decided by Mozilla, or by W3, I have no idea, but I can't see this issue in any other browser, they behave as you might expect.
|
|
||
Comment 7•1 year ago
•
|
||
Not wanting to debate really (particularly not on Bugzilla), but I want to clarify/address a few points:
(In reply to chris.spittles from comment #6)
People will use this to lay out pages or page parts that will require printing. Deciding behaviour like this massively affects how it can be used.
It's worth emphasizing that this is only an issue when a single grid row is taller than a page. If someone uses a grid to lay out "pages or page-parts" as you mentioned, with grid-rows that are smaller than a page or simply as-large-as a printed page, then everything should be fine and they wouldn't run into this issue. It's only when there's a single grid-row that is taller-than-a-page that will cause that grid-row to get pushed to the next page (if it looks like the next page will have more space).
Having said that, this is admittedly easy-to-trip for some sorts of layout, e.g. a traditional 3-column layout with a tall multiple-pages-long article in the middle. If the grid container in this situation is only defined with a single row, then it'll likely run up against this issue if there's content before it; it'll get pushed to the next page in an attempt to fit better.
Whether that [printing/splitting] behaviour was decided by Mozilla, or by W3,
The CSS grid spec has a fragmentation (pagination) section that doesn't define how pagination should work -- it does say page-breaks can occur between grid rows, and doesn't really say more than that. That happens to be roughly what we do right now, allowing pagebreaks between grid-rows (with more complicated behavior to handle splitting up the child elements that happen to straddle those pagebreaks-between-rows).
I can't see this issue in any other browser, they behave as you might expect.
Other browsers absolutely do have rough edges in this neighborhood. :) It's possible their heuristics for simple cases have happened to avoid this sort of issue for the particular content you've been working on, but there are absolutely variants of the attached testcase from comment 0 here that render in a similarly-broken way in WebKit and Chrome (which we handle better in some cases).
I'll attach one example that I just came up with, which renders broken in Chrome and WebKit (and "differently-broken"). Suffice to say that splitting a grid row that's taller than a page is non-trivial in general, and any approach will be problematic for some set of content. It's possible we could add special cases for simple situations (and perhaps that's what Chrome and/or Safari have done?), though for now we've just got our general approach discussed in comment 2.
|
|
||
Comment 8•1 year ago
•
|
||
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 contentthat 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.)
|
|
||
Updated•1 year ago
|
|
|
||
Comment 9•1 year ago
|
||
(side note, I filed https://bugs.chromium.org/p/chromium/issues/detail?id=1487868 on the Chrome behavior described in previous comment, since their quirks there seem particularly weird & potentially worth investigating.)
|
|
||
Updated•1 year ago
|
|
|
||
Comment 10•1 year ago
|
||
I appreciate you taking the time to explain and the example you posted. I wasn't out to argue, but I have experienced the exact issue described when laying out an entire page with grid and having the content section of the site be an entire grid row which often contains content that extends beyond the height of a page. Its made grid useless to us in these scenarios.
|
|
||
Comment 11•1 year ago
|
||
Thanks, that's good to know.
For what it's worth, I just filed bug 1857658 to investigate adding some special handling for the "grid with just one row which is taller than a page" special-case, since that's probably where most people might hit this (when using a grid for whole-page-layout without needing multiple rows), and it's conceivably a more tractable problem than making this work gracefully for all grids.
Description
•