1998701 - Printing tables spanning multiple pages show glitches

Status: UNCONFIRMED

(Core :: Layout: Tables, defect)

Description

[wdo362]

Attachment: 2025-11-06 15-43-07.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:140.0) Gecko/20100101 Firefox/140.0

Steps to reproduce:

After upgrading from FF 115.esr to FF 140.esr we see glitches when printing tables which span multiple pages.

Actual results:

The first page looks correct (like in FF 115) but on the following pages the top border of the table header which is repeated on every page is missing. Also at the bottom of every following page additional space having the background color of the table is appended to the bottom border.

Expected results:

Table on every page looking similar as it does with FF 115.

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Tables' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Daniel Holbert [:dholbert]]

Thanks for the bug report. Could you share a testcase or a sample document that reproduces the bug, so that we can investigate further?

(I can see in the attached screenshot that you needed to blur some content, so I understand that some of it might be confidential. If so, perhaps you can create a "dummy" version of this document, with bogus values, that still reproduces the bug? And/or, you're welcome to send the testcase via email (to me, dholbert at mozilla.com) if you're more comfortable doing that than posting a public testcase.

I was unable to reproduce any trouble with a quick attempt at a testcase, with a very tall table and a thead:

data:text/html,<style>td { height: 4in}</style><table border><thead><th>TABLE HEADER</th></thead><tr><td>Hi</td></tr><tr><td>Hi</td></tr><tr><td>Hi</td></tr><tr><td>Hi</td></tr><tr><td>Hi</td></tr><tr><td>Hi</td></tr>

Print-previewing that, I'm not seeing any meaningful difference between v115 and current versions of Firefox. (In particular, the table header has its border properly replicated on each page.)

Comment 3

[wdo362]

I can see in the attached screenshot that you needed to blur some content, so I understand that some of it might be confidential.

Yes exactly. This is an internal monitoring system for our customers.

Could you share a testcase or a sample document that reproduces the bug

Yes I can do. I will try to remove as much of complexity which isn't necessary to reproduce the problem and replace the data with dummy entries. Pleas allow a little bit of time for it.

Comment 4

[Daniel Holbert [:dholbert]]

Sure, no rush - thank you!

Please feel free to use the 'needinfo' field to tag me when you're able to share that testcase, to be sure I don't overlook it.

Comment 5

[wdo362]

Attachment: sample.html

Sample html file attached

Comment 6

[Daniel Holbert [:dholbert]]

Thanks - I can reproduce the behavior-change there.

A few observations:

• No interior borders (between rows/cells) show up at all in print/print-preview, in any browser, unless you check the print-dialog-box to print backgrounds.
• That's because this testcase's "borders" aren't actually CSS borders -- rather, they're bits of the table's background-color that are left uncovered-by-cells and are allowed to "shine through" to the foreground. Specifically, they're space that's left un-covered using the border-spacing property, which is not a border but rather space between the border-edge of adjacent cells.
• Like Firefox, Chrome doesn't paint any of this faux-border at the top of page 2. (I haven't yet seen a case where they paint an extra chunk of background-color at the bottom of a page, though.)

Comment 7

[Daniel Holbert [:dholbert]]

Here's where we changed from the old ("good") to new ("bad") behavior here:

INFO: Last good revision: 511c4cab0c008207c1ab7a1d4b14479f4f315f84 (2024-03-06)
INFO: First bad revision: 0027da61966ddaf727a4c543b4541d0e175cb354 (2024-03-07)
INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=511c4cab0c008207c1ab7a1d4b14479f4f315f84&tochange=0027da61966ddaf727a4c543b4541d0e175cb354

Looks like it was from bug 1863421, "Stop reserving row-spacing at the block-start edge in table continuations", and we made the change in part for interoperability-with-other-browsers and for consistency with how we do/don't reserve other space between elements on page-breaking. I suspect we didn't consider this "border-spacing being used as a faux-border" scenario. Though if other browsers don't have this behavior, then interoperability might require us to keep the new behavior (aside from the part about the thick background-area at the bottom of the page, which we should probably investigate and address...)

Note that if you want to get back the old behavior, you might investigate using true border here combined with border-collapse:collapse to get "true" borders between the cells, which should be painted properly on each page.

Comment 8

[BugBot [:suhaib / :marco]]

:TYLin, since you are the author of the regressor, bug 1863421, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.