[BC] border-collapse printing produces inconsistent results

REOPENED
Unassigned

Status

()

Core
Layout: Tables
P3
major
REOPENED
16 years ago
7 months ago

People

(Reporter: Mark McMillan, Unassigned)

Tracking

({regression, regressionwindow-wanted, testcase})

Trunk
Future
x86
Windows NT
regression, regressionwindow-wanted, testcase
Points:
---

Firefox Tracking Flags

(firefox55 ?, firefox56- fix-optional, firefox57 fix-optional)

Details

Attachments

(4 attachments, 2 obsolete attachments)

(Reporter)

Description

16 years ago
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

16 years ago
can you produce a testcase ?

Comment 2

16 years ago
-->
Assignee: rods → karnaze
(Reporter)

Comment 3

16 years ago
Created attachment 95995 [details]
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.
(Reporter)

Comment 4

16 years ago
Created attachment 95996 [details]
CSS to accompany HTML

This accompanies HTML 95995.

Comment 5

16 years ago
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

16 years ago
Created attachment 106219 [details]
Testcase with attached css.
Attachment #95995 - Attachment is obsolete: true

Comment 7

16 years ago
Is this still a problem with latest build?
Both print preview and printing workforme, linux trunk build 2003-02-01-22.

Comment 9

16 years ago
WFM 1.3b/OS X

Comment 10

16 years ago
Confirming.
When printing there are no border colors. Even though I clicked the "Print
background" is clicked.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 11

15 years ago
mass reassign to default owner
Assignee: karnaze → table
Component: Print Preview → Layout: Tables
QA Contact: sujay → madhur

Updated

15 years ago
Priority: -- → P3
Target Milestone: --- → Future

Updated

15 years ago
Keywords: testcase

Comment 12

15 years ago
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
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME

Comment 13

15 years ago
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

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

Comment 15

15 years ago
Reopening.
This is definitely not working in 20031114 PC/WinXP.  Print preview is fine,
printing produces no border.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

Comment 16

15 years ago
This seems to be an windows issue only.

Comment 17

15 years ago
Created attachment 135785 [details]
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

15 years ago
Created attachment 135786 [details]
Testcase (corrected version)

Apologies for the spam. This version has the id for the medium table matching
the css.
Attachment #135785 - Attachment is obsolete: true

Comment 19

14 years ago
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]
Summary: CSS 'border-collapse:collapse' produces inconsistent results → [BC] border-collapse printing produces inconsistent results

Comment 20

14 years ago
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

14 years ago
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

13 years ago
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
Assignee: layout.tables → nobody
QA Contact: madhur → layout.tables

Comment 23

a year ago
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

a year ago
Created attachment 8856269 [details]
print-border-bug-on-the-following-pages.html
Attachment #8856269 - Flags: feedback+

Comment 25

10 months ago
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.
tracking-firefox56: --- → ?
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.
status-firefox55: --- → ?
status-firefox56: --- → fix-optional
status-firefox57: --- → affected
tracking-firefox56: ? → -
Keywords: regression, regressionwindow-wanted
A bug this old should not be used to track a more recent regression.

Comment 28

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

Comment 29

10 months ago
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
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.
status-firefox57: affected → fix-optional
You need to log in before you can comment on or make changes to this bug.