Last Comment Bug 428109 - 'Print Selection' prints nothing on page with very wide div
: 'Print Selection' prints nothing on page with very wide div
Status: NEW
: testcase
Product: Core
Classification: Components
Component: Printing: Output (show other bugs)
: Trunk
: All All
-- normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Jet Villegas (:jet)
Mentors:
: 448549 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-09 15:26 PDT by Daniel Holbert [:dholbert]
Modified: 2012-08-28 09:10 PDT (History)
2 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase 1 (30-in wide div) (210 bytes, text/html)
2008-04-09 15:26 PDT, Daniel Holbert [:dholbert]
no flags Details
reference 1 (12-in wide div) (210 bytes, text/html)
2008-04-09 15:27 PDT, Daniel Holbert [:dholbert]
no flags Details
testcase 2 (20-in-wide div) (210 bytes, text/html)
2008-04-09 15:28 PDT, Daniel Holbert [:dholbert]
no flags Details
testcase 3 (100-in wide div) (211 bytes, text/html)
2008-04-09 15:56 PDT, Daniel Holbert [:dholbert]
no flags Details

Description User image Daniel Holbert [:dholbert] 2008-04-09 15:26:33 PDT
Created attachment 314709 [details]
testcase 1 (30-in wide div)

This bug was discovered in bug 402264 comment 41, and it's present in both Firefox 2 and Trunk.

STEPS TO REPRODUCE:
 1. Open testcase
 2. Select any chunk of text (or Ctrl-A to select all)
 3. Ctrl-P to print
 4. Select "Print Selection"
    (in FF2, choose "Selection" under "Print Range")
    (in FF3 under Linux, choose the "Options" tab, and check "Print Selection Only")
  5. Go ahead and print (either to file or to a real printer)

EXPECTED OUTPUT: selected text visible
ACTUAL OUTPUT:  blank page
Comment 1 User image Daniel Holbert [:dholbert] 2008-04-09 15:27:40 PDT
Created attachment 314710 [details]
reference 1 (12-in wide div)

This testcase just has a skinnier div (though it's still wider than a page), and it works fine for print-selection.
Comment 2 User image Daniel Holbert [:dholbert] 2008-04-09 15:28:17 PDT
Created attachment 314711 [details]
testcase 2 (20-in-wide div)

This testcase also shows the bug, with a 20-inch wide div.
Comment 3 User image Daniel Holbert [:dholbert] 2008-04-09 15:56:17 PDT
Created attachment 314717 [details]
testcase 3 (100-in wide div)

It's possible the smaller divs work on Windows (I'm not sure, as my windows box is being weird right now.)  However, this version with a 100-inch-wide div definitely doesn't work on Windows.
Comment 4 User image Daniel Holbert [:dholbert] 2008-04-09 16:18:21 PDT
Note that, while they break in "print selection" mode, these testcases all work fine when printed *normally* (not as selection) -- the right edge of the div just gets cut off, which is fine.

Briefly, here's the code that's responsible for this discrepancy:

If we're doing 'print selection' mode, we tweak mPrt->mPrintFrameType here:
  http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/layout/printing/nsPrintEngine.cpp&rev=1.174#2848

And that change to mPrintFrameType affects which shrink ratio we choose, here:
   http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/layout/printing/nsPrintEngine.cpp&rev=1.174#1815

1818    float ratio;
1819    if (mPrt->mPrintFrameType == nsIPrintSettings::kFramesAsIs || mPrt->mPrintFrameType == nsIPrintSettings::kNoFrames) {
1820      ratio = mPrt->mShrinkRatio - 0.005f; // round down
1821    } else {
1822      ratio = aPO->mShrinkRatio - 0.005f; // round down
1823    }

In normal printing, we use mPrt's shrink ratio, but in print-selection, we end up using aPO's shrink ratio.

This matters because mPrt->mShrinkRatio is capped (on the lower end) to 0.60, here...
   http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/layout/printing/nsPrintEngine.cpp&rev=1.174#1665

... but no such capping is done for aPO's shrink ratio.

So, in summary:  if we have a very wide div, we'll get a very small shrink ratio (e.g. 0.15), in an effort to make it fit. For normal-printing, that shrink ratio is capped with a lower-bound of 0.60.  If we do print-selection, however, we don't ever cap it, so we keep a very small print ratio.

(I think this might end up causing the bug because of the loss of precision when we scale up by large amounts.)
Comment 5 User image :Hb 2009-12-19 14:39:03 PST
*** Bug 448549 has been marked as a duplicate of this bug. ***

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