627 bytes, text/css
59.41 KB, text/html
1.60 KB, text/html
10.04 KB, text/html
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.
can you produce a testcase ?
Assignee: rods → karnaze
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.
It also happens at least in Windows ME and XP, and not only affects the print preview, but also the actual printed pages.
Created attachment 106219 [details] Testcase with attached css.
Attachment #95995 - Attachment is obsolete: true
Is this still a problem with latest build?
Both print preview and printing workforme, linux trunk build 2003-02-01-22.
WFM 1.3b/OS X
Confirming. When printing there are no border colors. Even though I clicked the "Print background" is clicked.
Status: UNCONFIRMED → NEW
Ever confirmed: true
mass reassign to default owner
Assignee: karnaze → table
Component: Print Preview → Layout: Tables
QA Contact: sujay → madhur
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
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.
*** Bug 225968 has been marked as a duplicate of this bug. ***
Reopening. This is definitely not working in 20031114 PC/WinXP. Print preview is fine, printing produces no border.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
This seems to be an windows issue only.
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
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
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
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.
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
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
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;
Created attachment 8856269 [details] print-border-bug-on-the-following-pages.html
Attachment #8856269 - Flags: feedback+
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.
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.