Closed Bug 570362 Opened 12 years ago Closed 12 years ago
Vision rebate form has truncated content when printed, with ":after", padding, float:left, and nested tables
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
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
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 )
Requesting blocking1.9.3, as this is a printing regression since 1.9.1.
blocking2.0: --- → ?
Summary: Truncated print output, with ":after", padding, float:left, and nested tables → CooperVision rebate form has truncated content when printed, with ":after", padding, float:left, and nested tables
(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.
> I suspect bug 495385 in the regression range, though I'm not completely sure. I just confirmed that via bisect.
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.
This just removes the space after the insertStuffAfterMe div.....
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?
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 184.108.40.206, too -- so, this issue goes back a long way. ("longstanding" indeed) (Note: 220.127.116.11 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.
Assignee: nobody → dholbert
Status: NEW → ASSIGNED
Both testcases in this patch are fixed by bug 563584.
Assignee: dholbert → dbaron
blocking2.0: ? → beta5+
Depends on: 563584
er, all three testcases
That's great news - thanks dbaron!
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b4
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.)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.