163445 - [BC] border-collapse printing produces inconsistent results

Status: NEW

(Core :: Layout: Tables, defect, P3)

Description

[Mark McMillan]

When using the CSS command 'border-collapse:collapse' on tables.  The table will
usually render correctly in the browser window, but not in the print-preview window.

Usually the print preview will render correctly (with regard to the borders) any
part of a table which starts on that page.  However, following pages of the
table do not render correctly. (e.g. f a new table starting mid-way down a page
it will render correctly for the rest of that page, but not for following
pages.)  The rendering of identical HTML / CSS on following pages of the table
is wildly inconsistent, often producing different results on each page.

When printed, the document looks different to the rendering produced by both the
browser windows.  Often with no borders rendered at all, in any part of any table.

Comment 1

[Olivier Cahagne]

can you produce a testcase ?

Comment 2

[rods (gone)]

-->

Comment 3

[Mark McMillan]

Attachment: HTML testcase for bug

This HTML (together with the CSS) is a representative test-case.  It renders
fine in the Mozilla browser window.  In Mozilla 1.0 Print Preview window the
rendering is nothing like that from the browser, and inconsistent between
pages.	The printed result is different again.	The latest overnight builds
much improve print preview rendering (but not printing).  However, borders are
still inconsistent between pages (alongside other problems), and not up to the
standard of IE.

Comment 4

[Mark McMillan]

Attachment: CSS to accompany HTML

This accompanies HTML 95995.

Comment 5

[Marcos Mezo]

It also happens at least in Windows ME and XP, and not only affects the print
preview, but also the actual printed pages.

Comment 6

[José Jeria]

Attachment: Testcase with attached css.

Comment 7

[José Jeria]

Is this still a problem with latest build?

Comment 8

[Boris Zbarsky [:bzbarsky]]

Both print preview and printing workforme, linux trunk build 2003-02-01-22.

Comment 9

[Chris Casciano]

WFM 1.3b/OS X

Comment 10

[José Jeria]

Confirming.
When printing there are no border colors. Even though I clicked the "Print
background" is clicked.

Comment 11

[karnaze (gone)]

mass reassign to default owner

Comment 12

[Max Kanat-Alexander]

Comment 10 did not include a build number or a platform, and there are several
other comments which do include a build number and platform and say WFM.

The testcase also WFM Win2K Mozilla 1.4final.

So, marking WFM. Reporter (Mark McMillan): If you can duplicate this in a recent
build, please reopen the bug.

Also, make sure that you check if it happens in both quirks and standards mode,
since the testcase is in quirks.

-M

Comment 13

[José Jeria]

Max K-A, did you really test this yourself when you marked this as WFM?
When I tested this (comment 10), I was using a daily build on Windows XP. Cant
retest though, dont have a printer anymore. 

Comment 14

[Bill Mason]

*** Bug 225968 has been marked as a duplicate of this bug. ***

Comment 15

[Bill Mason]

Reopening.
This is definitely not working in 20031114 PC/WinXP.  Print preview is fine,
printing produces no border.

Comment 16

[José Jeria]

This seems to be an windows issue only.

Comment 17

[Mark Tyndall]

Attachment: Testcase (modified from 225968 testcase)

I found that Win2K Mozilla 1.5 Gecko/20031007 is breaking as described in bug
225968; I was tweaking its testcase but have come to this bug to report.

In the attached case, borders marked "thin" or "medium" do not print out; they
do appear on print preview.

The 2px border prints and is around 1mm thick; the "thick" border prints and is
quite a bit thinner - maybe around 0.5mm

Comment 18

[Mark Tyndall]

Attachment: Testcase (corrected version)

Apologies for the spam. This version has the id for the medium table matching
the css.

Comment 19

[fantasai]

Just as a note: I got some strange results for the keyword borders when using the
separate borders model; the borders were thin on all and overshot the corners.

[Reconfirming on Win2k, build id 2004032807]

Comment 20

[Christopher Taylor]

I'm having the same problem in Mozilla 1.6 release when using CSS
collapse-border: collapse.  Borders between cells printed on the first page work
fine, but don't show up on subsequent pages.

If you don't use tbody or thead, the borders show up correctly, minus the header
I want on every page.

Comment 21

[Christopher Taylor]

If you slowly scroll the print preview pane, you'll notice that the preview will
draw the collapsed borders on page # > 1 until the thead is displayed.  There
must be some sort of conflict between using <thead> and the collapsed borders in
the body

Comment 22

[Wayne Mery (:wsmwk)]

can someone confirm fails or works?   WFM (I think) for attachment 106219 [details]

however attachment 135786 [details] - thin border box 2 doesn't preview when scale set higher than 200% (suspect this is a different bug)

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 and
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20051228 SeaMonkey/1.5a

Comment 23

[forkik]

Still do not render on print left border of the table on the following pages, but only when the table is inside a block with CSS: position: absolute; top: 0; right: 0; bottom: 0; left: 0;

Comment 24

[forkik]

Attachment: print-border-bug-on-the-following-pages.html

Comment 25

[bugzilla]

This seems to be a regression. I regularly use a web application that generates a table that I need to print out. I am sure it worked correctly some months ago, but when I printed the table again today, the table grid was only visible on page 1.

Here is another testcase:
http://sandbox.pigsgrame.de/demos/bordercollapse/

The page has a table where the table element itself and the cells (td) have a 1px solid border (defined in the style section of the page header). border-collapse:collapse is defined at table level. If you open the print preview dialog on this page, the table will only have visible borders on the first page. If you actually print the document, the result has the same wrong appearance.

Comment 26

[Liz Henry (:lizzard) (relman/hg->git project)]

It would be good to get a regression window here. Maybe it broke again in April?
 
I don't think we need to track this for 56 as it is a fairly minor regression.
Happy to take a patch while 56 is in beta, especially if we can verify a fix in Nightly.

Comment 27

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

A bug this old should not be used to track a more recent regression.

Comment 28

[Alice0775 White]

at least, the problem of Comment 25 is duplication of Bug 1394249

Comment 29

[NEIA SAS]

This bug is the same that https://bugzilla.mozilla.org/show_bug.cgi?id=1392882
The bug don't exists in Firefox 54 and appeared in Firefox 55

Comment 30

[Liz Henry (:lizzard) (relman/hg->git project)]

I'm going to un-dupe bug 1392882 and track the issue there. It sounds like this may have worked, at least for some test cases described here and in the other bug, in 53 and then regressed in 54.

Comment 31

[Alice0775 White]

left border is missing of 2nd page with Attachment #8856269 [details]

Regression window:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=688c44602a55&tochange=5f349409c9d5

Suspect: bug 155955

Comment 32

[Raluca Popovici, Desktop QA]

I can reproduce this issue on my machines Win 10 and MacOS11 on the latest Firefox Nightly 96.0a1 with Test Case from comment 18 and with TC: http://sandbox.pigsgrame.de/demos/bordercollapse/. See my results attached.

Comment 33

[Raluca Popovici, Desktop QA]

Attachment: comment18MAcOS11.png

Comment 34

[Raluca Popovici, Desktop QA]

Attachment: comment25MacOS11.png

Comment 35

[Raluca Popovici, Desktop QA]

Attachment: comment18Win10.png

Comment 36

[Raluca Popovici, Desktop QA]

Attachment: comment25Win10.png