Last Comment Bug 295815 - Floats truncated on page boundary when printing (Print of the second page of Mapquest's driving directions is blank)
: Floats truncated on page boundary when printing (Print of the second page of ...
Status: RESOLVED FIXED
Testcase & description in comment #10
: dataloss, fixed1.8, regression, testcase, top100
Product: Core
Classification: Components
Component: Printing: Output (show other bugs)
: Trunk
: All All
: -- normal with 1 vote (vote)
: ---
Assigned To: Robert O'Callahan (:roc) (email my personal email if necessary)
:
Mentors:
http://www.mapquest.com/directions/ma...
: 296279 310233 (view as bug list)
Depends on: 378027
Blocks: 240276 mapquest
  Show dependency treegraph
 
Reported: 2005-05-28 10:45 PDT by jt.marsh
Modified: 2007-04-23 18:27 PDT (History)
9 users (show)
asa: blocking1.8b5+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Testcase printed on Firefox 1.0.6 (how it should look) (131.48 KB, application/pdf)
2005-08-06 09:35 PDT, Tom Hessman
no flags Details
Testcase printed on the 2005-08-05 Firefox build (shows the problem) (90.81 KB, application/pdf)
2005-08-06 09:38 PDT, Tom Hessman
no flags Details
testcase (7.70 KB, text/html)
2005-09-28 08:22 PDT, Uri Bernstein (Google)
no flags Details
fix (1.83 KB, patch)
2005-09-30 10:50 PDT, Robert O'Callahan (:roc) (email my personal email if necessary)
dbaron: review+
dbaron: superreview+
mscott: approval1.8b5+
Details | Diff | Splinter Review

Description jt.marsh 2005-05-28 10:45:54 PDT
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050527 Camino/0.8+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050527 Camino/0.8+

Printing out Mapquest's driving directions results in a blank second page
(except the footer and header). This happens in both Camino and Firefox. It
prints correctly using Safari.

Reproducible: Always

Steps to Reproduce:
1. Go to mapquest.com
2. Get directions.
3. Go to the printable page.
4. Print

Actual Results:  
Second page is blank.

Expected Results:  
Second page should contain the remaining maps and text.
Comment 1 zug_treno 2005-05-29 02:59:46 PDT
Related to bug 274424?
Comment 2 Robert Praetorius 2005-06-02 07:33:25 PDT
*** Bug 296279 has been marked as a duplicate of this bug. ***
Comment 3 Tom Hessman 2005-08-06 09:31:05 PDT
To clairfy, this bug occurs when you get directions with MapQuest and try to
print them from the printer-friendly view, not the "normal" view (the problems
with that are documented in bug 274424).  As the reporter indicated, the first
page prints fine, but the second page is blank (except for the header and
footer), instead of containing the rest of the directions and maps.  If there
are supposed to be more than two pages (as in the following testcase), pages
after the second don't exist at all in the printout (not even as blank pages). 
Print Preview does match what actually prints.

To reproduce, go to http://tinyurl.com/7z3f7 (a sample set of directions from
New York City to Boston), and then use print preview.  I plan to attach PDF
examples of how it should look (printed from Firefox 1.0.6) and how it ends up
looking (printed from the 2005-08-05 Firefox trunk build).

Based on my testing, this bug occurs in current trunk builds (2005-08-05) of
Firefox and Seamonkey, both on Windows and Mac OS X.  This bug does NOT occur on
current 1.7-branch builds, such as Firefox 1.0.6, Mozilla 1.7.11, or Camino
0.8.4, so it definitely seems to be a trunk-only problem.
Comment 4 Tom Hessman 2005-08-06 09:35:17 PDT
Created attachment 191814 [details]
Testcase printed on Firefox 1.0.6 (how it should look)

This PDF is a printout of my testcase showing how it prints from Firefox 1.0.6.
 This is also what the printout looks like printed from Mozilla 1.7.11, Camino
0.8.4, and is similar to how it looks when printed from non-Gecko browsers such
as Safari.  Note that it is 3 pages long.
Comment 5 Tom Hessman 2005-08-06 09:38:59 PDT
Created attachment 191815 [details]
Testcase printed on the 2005-08-05 Firefox build (shows the problem)

This PDF is a printout of my testcase showing how it prints on the 2005-08-05
trunk build of Firefox.  This is also how the printout looks on the 2005-08-05
trunk build of Seamonkey.  Note that the second page is blank, except for the
header and footer, and that there is no third page.
Comment 6 Tom Hessman 2005-08-08 18:31:34 PDT
Nominating to block aviary-1.5, as this is a major regression with a top 100
website.  Also nominating to block 1.8b4.
Comment 7 Chris Blore 2005-08-08 23:11:05 PDT
As zug_treno said, this is a dupe of bug 274424

*** This bug has been marked as a duplicate of 274424 ***

*** This bug has been marked as a duplicate of 274424 ***
Comment 8 Robert Praetorius 2005-08-15 08:14:09 PDT
I'm with Mr. Hessman on this.  This is not a dupe of 274424.
Mr. Hessman's description DOES match my 296279 (so I'm happy
to accept that 296279 is a dupe of 295815).

What do the original posters of this bug and 274424 say?
Comment 9 Uri Bernstein (Google) 2005-09-28 07:36:49 PDT
*** Bug 310233 has been marked as a duplicate of this bug. ***
Comment 10 Uri Bernstein (Google) 2005-09-28 08:22:15 PDT
Created attachment 197703 [details]
testcase

This testcase demonstrates the real problem here. The testcase contains a
left-floated div containing lots of text, ending with a line reading "this is
the bottom of the FLOAT".
This div is then followed by a line reading "this is the bottom of the PAGE".

When printing, only the part of the float which fits into the first page is
printed, followed, on the second page, by the text outside the float. You can
see that the text "this is the bottom of the FLOAT" appears nowhere.
Comment 11 Uri Bernstein (Google) 2005-09-28 08:29:21 PDT
Un-duping, changing summary, and marking "regression". The testcase I attached
WFM on Firefox 1.0, for which bug 274424 was filed - so this can not be the same
bug.
Comment 12 Uri Bernstein (Google) 2005-09-28 08:31:29 PDT
Sample URL from bug 310233.
Comment 13 Uri Bernstein (Google) 2005-09-28 08:59:46 PDT
This regressed between 2005-04-28 and 2005-04-29, probably by bug 240276.

CCing ROC and BZ, and requesting blocking 1.8b5, as this regression might affect
many pages.
Comment 14 Robert O'Callahan (:roc) (email my personal email if necessary) 2005-09-30 10:50:17 PDT
Created attachment 198016 [details] [diff] [review]
fix

This is fairly simple and low-risk fix. It is possible for the
available-space-rect height to be set to UNCONSTRAINED during pagination, when
we want to force at least part of the the float to fit. But the mContentArea
height will still be constrained so we should only look at that.
Comment 15 Robert O'Callahan (:roc) (email my personal email if necessary) 2005-09-30 14:57:27 PDT
checked in.
Comment 16 Robert O'Callahan (:roc) (email my personal email if necessary) 2005-09-30 14:59:57 PDT
Comment on attachment 198016 [details] [diff] [review]
fix

need approval for this blocker
Comment 17 Scott MacGregor 2005-09-30 15:22:23 PDT
Comment on attachment 198016 [details] [diff] [review]
fix

I'm going to take the liberty of approving this patch for the branch.
Comment 18 Robert O'Callahan (:roc) (email my personal email if necessary) 2005-09-30 15:27:17 PDT
checked into branch.
Comment 19 Tom Hessman 2005-10-01 09:12:18 PDT
This appears to be fixed using the 2005-10-01 1.8-branch build on Mac OS X. 
Great work!

Note You need to log in before you can comment on or make changes to this bug.