Closed Bug 419917 Opened 12 years ago Closed 12 years ago

Printed page contents are reflected inside bordered tables (Linux-only)

Categories

(Core :: Graphics, defect, P2, blocker)

x86
Linux
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: dholbert, Assigned: vlad)

References

Details

(Keywords: regression, testcase)

Attachments

(9 files)

Attached file testcase 1
Steps to reproduce:
 1. Print testcase.

ACTUAL RESULTS:
 The text is duplicated inside the table, with the lines reversed.  See upcoming print-to-file results.

This doesn't happen in print-preview, so I'm guessing it's a rendering/graphics-related issue.

Bug reproduces on Linux on both FF3b3 and on latest trunk.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4pre) Gecko/2008022704 Minefield/3.0b4pre
Flags: blocking1.9?
Keywords: testcase
Just for good measure, here's a screenshot of the PDF, for easier viewing within Firefox.
Sorry -- by "dashed area" in the testcase, I meant "on top of the table".  if that's not clear.
Attached file reference case 1
If I remove the border from the table, or replace it with a *styled* border (as in this reference case), then the bug goes away.
Attachment #306081 - Attachment description: testcase 1, printed to PDF (See bug here) → testcase 1, printed to PDF (BROKEN)
Attached file testcase 2
Ok -- as the next two testcases show, it looks like the table behaves simply as a doorway to a vertically-reflected copy of the entire page.

When printed, this testcase shows the very bottom of the page (list items 27-36) reflected in the table at the very top of the page.
Attached file testcase 3
This is the same as testcase 2, but now with the table at the *bottom* of the page.

Since it's at the bottom, it now shows the *top* of the page reflected upside down in it, when printed.
Summary: Text below a bordered table is duplicated inside the table, with lines reversed → Printed page contents are reflected inside bordered tables
Summary: Printed page contents are reflected inside bordered tables → Printed page contents are reflected inside bordered tables (Linux-only)
FWIW, I can't reproduce this on Mac or Windows -- pretty sure this is Linux-only.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P3
Vlad: can we elevate this to P2 or P1?  It causes corruption on printed documents that use bordered tables, making the contents of the tables largely unreadable (because other content is drawn on top of them).  It seems pretty serious to me.
this regressed between seamonkey 2008-02-19-09-trunk and 2008-02-20-08-trunk.  I don't see anything obvious in that range...
(In reply to comment #12)
> this regressed between seamonkey 2008-02-19-09-trunk and 2008-02-20-08-trunk. 
> I don't see anything obvious in that range...

I'm confused by those dates you're giving for the regression range... Are you saying it regressed between February 19th and 20th, of 2008?

'cause that regression range isn't what I'm seeing here -- I can definitely reproduce the bug using a nightly from February 2nd,2008.
(build id: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2008020204 Minefield/3.0b3pre)
Ok, so this has two separate regression ranges.  (tested using testcase 3 aka attachment 306100 [details])


***  The first regression is between 2008-01-20 and 2008-01-21.  After this change, the table no longer appears at all in printed documents.
Bonsai link:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-01-20+03%3A30%3A00&maxdate=2008-01-21+04%3A30%3A00&cvsroot=%2Fcvsroot

Bug 193001 looks like the main candidate for this first regression.


***  The second regression is between 2008-01-25 and 2008-01-26.  After this change, I see the table again in a printed document, but the text is reflected in it as described in earlier comments.

Bonsai link: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-01-25+03%3A30%3A00&maxdate=2008-01-26+04%3A30%3A00&cvsroot=%2Fcvsroot

Looks like the second regression was caused by bug 413878.
Blocks: 193001, 413878
(In reply to comment #14)
> Bug 193001 looks like the main candidate for this first regression.

Or possibly bug 413169, which was a cairo tweak.
> 'cause that regression range isn't what I'm seeing here -- I can definitely
> reproduce the bug using a nightly from February 2nd,2008.

OK, my testcase was actually a bit different (fieldset instead of a table), but the effect is identical.  Probably the earliest regression is the real regression and the rest is the bug getting triggered in other situations.
So two things offhand... one, the text inside the table is bitmapped, this is essentially bug 416121.  The other is that the inverse line ordering isn't all -that- weird.  PostScript's native coordinate space is with Y increasing, so if we're somehow re-rendering things without having the right coordinate flip set up, things will appear to show up in the opposite order.  (Oddly, text won't get fipped by this, it just moves the origin of the text.)
Component: Printing → GFX: Thebes
QA Contact: printing → thebes
Flags: tracking1.9+ → blocking1.9+
Priority: P3 → P2
Assignee: nobody → vladimir
I'm about to get on a flight, but could someone who has a build and can easily reproduce this apply http://tinyurl.com/2d7u2h and see if that fixes the problem?  Only the first hunk needs to be applied, the changes in cairo-types-private are just there to make sure that type of problem doesn't happen again.
Duplicate of this bug: 420526
(In reply to comment #18)
> could someone who has a build and can easily reproduce this apply
> http://tinyurl.com/2d7u2h and see if that fixes the problem?

No, it doesn't, can still reproduce the bug with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4pre) Gecko/2008030214 Minefield/3.0b4pre with the patch applied.

checkout start: So 2. Mär 14:32:43 CET 2008
Curiously, the userContent.css workaround mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=416121#c5 works also for this bug. Maybe I'm wrong, but it looks like both bugs were just different symptoms of one and the same underlying issue.

I apologize for the blind guess, but can it be something similar to https://bugzilla.mozilla.org/show_bug.cgi?id=378307#c5 ??
Just committed a fix for this in upstream cairo; I'll update mozilla's cairo tomorrow.  (cairo commit d89edde84de9cec9ce6f76f4f2c44dd9c1220528)
Should be fixed by the cairo update.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Flags: in-testsuite?
Duplicate of this bug: 420959
Verified fixed, printing testcases 1 and 3, in 
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5pre) Gecko/2008030604 Minefield/3.0b5pre

Thanks Vlad!
Status: RESOLVED → VERIFIED
Duplicate of this bug: 420682
You need to log in before you can comment on or make changes to this bug.