570362 - CooperVision rebate form has truncated content when printed, with ":after", padding, float:left, and nested tables

Status: VERIFIED FIXED

(Core :: Printing: Output, defect)

Description

[Daniel Holbert [:dholbert]]

STEPS TO REPRODUCE:
 1. Load URL.
 2. Select brand "Avaira" from dropdown, and press 'Next'
 3. Print-preview page.
 4. Examine bottom of second page.

EXPECTED RESULTS:
 - All content should be present.
ACTUAL RESULTS:
 - Some content at bottom of second page is missing (for me, the bottom part of the "Eye Doctor Information" section is missing).  Third page picks up at the beginning of the next section, "Required Proof of Purchase".

REDUCED TESTCASE:
See attached reduced testcase -- when I print-preview that, I see three pages.  The first & third are blank, and there are only 7 lines of text on the second page. (when there's actually 30 lines of content to be printed)

In versions of firefox before the regression, the reduced testcase has no blank pages & no missing lines. (and many more pages are printed)

NOTE: I actually reduced the testcase from a *submitted form* -- not the editable version at the URL given.  I think the problem is the same (or related) on both pages, though, because the regression ranges are the same.

REGRESSION RANGE:
WORKS:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090623 Minefield/3.6a1pre
http://hg.mozilla.org/mozilla-central/rev/c575412d976a

BROKEN:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090624 Minefield/3.6a1pre
http://hg.mozilla.org/mozilla-central/rev/5fe89f2c22f0

RANGE:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c575412d976a&tochange=5fe89f2c22f0

Comment 1

[Daniel Holbert [:dholbert]]

Note: This is a regression in Firefox 3.6 (and newer),  w.r.t. Firefox 3.5.

This persists in my trunk build:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a5pre) Gecko/20100605 Minefield/3.7a5pre

Comment 2

[Daniel Holbert [:dholbert]]

I suspect bug 495385 in the regression range, though I'm not completely sure.  (Note that its checkin was known to break a pagination reftest, which was marked as "fails" in the reftest manifest as part of the checkin:
http://hg.mozilla.org/mozilla-central/diff/c6c685aa0379/layout/reftests/pagination/reftest.list
)

Comment 3

[Daniel Holbert [:dholbert]]

Requesting blocking1.9.3, as this is a printing regression since 1.9.1.

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase 1

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to comment #0)
> NOTE: I actually reduced the testcase from a *submitted form* -- not the
> editable version at the URL given.  I think the problem is the same (or
> related) on both pages, though, because the regression ranges are the same.

Also: the submitted form is supposed to be printed out & snail-mailed to CooperVision, in order for the rebate check to be sent, and the instructions on the completed form say to "include all pages".  So, for people sending these rebates, it's actually a fairly significant issue that the printed output is missing some content and has blank pages -- it means they might not be able to receive their rebate checks, if they're using Firefox 3.6 or newer.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> I suspect bug 495385 in the regression range, though I'm not completely sure. 

I just confirmed that via bisect.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Putting an   before the float, or just making the insertStuffAfterMe div "white-space: pre" makes the bug go away for some reason...

And if I eliminate enough whitespace in the minimal testcase, I get the problem showing up in Fx 3.5 as well, which makes sense.  So looks like we just had a longstanding problem that not creating the textframes triggered.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase that shows the problem in 3.5

This just removes the space after the insertStuffAfterMe div.....

Comment 9

[Boris Zbarsky [:bzbarsky]]

Attachment: Without :after, still showing the problem n 3.5 and trunk

Comment 10

[Boris Zbarsky [:bzbarsky]]

Set table cell incomplete 0x17383b8
###!!! ASSERTION: Shouldn't be incomplete if availableHeight is UNCONSTRAINED.: 'aReflowState.availableHeight != NS_UNCONSTRAINEDSIZE', file /Users/bzbarsky/mozilla/css-frameconst/mozilla/layout/generic/nsBlockFrame.cpp, line 1388

is probably the right place to start debugging this...

Daniel, do you want to give it a shot?

Comment 11

[Daniel Holbert [:dholbert]]

Thanks for the analysis, Boris!

(In reply to comment #9)
> Created an attachment (id=450600) [details]
> Without :after, still showing the problem n 3.5 and trunk

I've confirmed that this "without :after" testcase is broken in Firefox 3.0.19 and 2.0.0.18, too -- so, this issue goes back a long way. ("longstanding" indeed) (Note: 2.0.0.18 differs slightly in that it's missing the first blank page -- it just has 2 pages, with table-rows 1-7 on page 1 and nothing on page 2.)

(In reply to comment #10) 
> Daniel, do you want to give it a shot?

Sure! Might not get to it right away, but I'll take a look in the next week or two.

Comment 12

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

Both testcases in this patch are fixed by bug 563584.

Comment 13

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

er, all three testcases

Comment 14

[Daniel Holbert [:dholbert]]

That's great news - thanks dbaron!

Comment 15

[Mike Beltzner [:beltzner, not reading bugmail]]

dbaron: does comment 12 mean that this is FIXED by bug 563584?

Comment 16

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

yes

Comment 17

[Daniel Holbert [:dholbert]]

Verified fixed on trunk, using all testcases here.
Mozilla/5.0 (X11; Linux i686; rv:2.0b5pre) Gecko/20100830 Firefox/4.0b5pre

(From a quick test of the original page, it's now changed to be less than 1 page, so I can't test this there anymore.)