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

Status: VERIFIED FIXED

(Core :: Graphics, defect, P2)

Description

[Daniel Holbert [:dholbert]]

Attachment: 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

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: testcase 1, printed to PDF (BROKEN)

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screenshot of testcase 1, as printed

Just for good measure, here's a screenshot of the PDF, for easier viewing within Firefox.

Comment 3

[Daniel Holbert [:dholbert]]

Sorry -- by "dashed area" in the testcase, I meant "on top of the table".  if that's not clear.

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: 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.

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: reference case 1, printed to PDF (WORKS)

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: 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.

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: testcase 2, printed to PDF (BROKEN)

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: 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.

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: testcase 3, printed to PDF (BROKEN)

Comment 10

[Daniel Holbert [:dholbert]]

FWIW, I can't reproduce this on Mac or Windows -- pretty sure this is Linux-only.

Comment 11

[Daniel Holbert [:dholbert]]

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.

Comment 12

[Andrew Schultz]

this regressed between seamonkey 2008-02-19-09-trunk and 2008-02-20-08-trunk.  I don't see anything obvious in that range...

Comment 13

[Daniel Holbert [:dholbert]]

(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)

Comment 14

[Daniel Holbert [:dholbert]]

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.

Comment 15

[Daniel Holbert [:dholbert]]

(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.

Comment 16

[Andrew Schultz]

> '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.

Comment 17

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

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.)

Comment 18

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

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.

Comment 20

[Ilja Sekler]

(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

Comment 21

[Ilja Sekler]

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 ??

Comment 22

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Just committed a fix for this in upstream cairo; I'll update mozilla's cairo tomorrow.  (cairo commit d89edde84de9cec9ce6f76f4f2c44dd9c1220528)

Comment 23

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Should be fixed by the cairo update.

Comment 25

[Daniel Holbert [:dholbert]]

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!