421890 - "Print Selection" prints blank pages

Status: RESOLVED DUPLICATE of bug 402264

(Core :: Printing: Output, defect, P2)

Description

[Gabriele Best [:Gabri]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008031004 Minefield/3.0b5pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008031004 Minefield/3.0b5pre

If I need to print only a selection of words, Firefox 3 don't print anything.

Reproducible: Always

Steps to Reproduce:
1.Click on File-Print... (CTRL+P)
2.Click on "Selection" radio button
3.Print the page
Actual Results:  
Page is not printed

Comment 1

[Mariana]

Confirmed, reproducible for me too.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008031004 Minefield/3.0b5pre
OS: Windows XP

Comment 2

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

--> Core::Printing

Comment 3

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

I can confirm this on Vista; a blank page comes out of my printer after a few seconds of it thinking about it.

Comment 4

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

One more for dholbert... can someone check to see if this happens on Linux or MacOS X?

Comment 5

[Daniel Holbert [:dholbert]]

I see this on Linux, as well.

OS/Platform --> All

Comment 6

[Daniel Holbert [:dholbert]]

Regression range:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3pre) Gecko/20070320 Minefield/3.0a3pre
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3pre) Gecko/20070321 Minefield/3.0a3pre

Bonsai link:  http://tinyurl.com/ytbw9t

Comment 7

[Daniel Holbert [:dholbert]]

I think Bug 374050 looks like most likely culprit...  Maybe it's related to this comment from that checkin, which we've still got in the code:

 852         // I'm leaving this in a broken state for the moment; we should
 853         // be measuring/scaling with the print device context, not the
 854         // screen device context, but this is good enough to allow
 855         // printing reftests to work.

http://mxr.mozilla.org/seamonkey/source/layout/base/nsDocumentViewer.cpp#852

Comment 8

[Daniel Holbert [:dholbert]]

(In reply to comment #7)
> I think Bug 374050 looks like most likely culprit...  Maybe it's related to
> this comment

Scratch that, we don't actually hit the code near that comment, because mIsPageMode is 0 when we get there.

So, not sure which checkin would've caused this...


Here's one place where we react to the "print-selection-only" setting:

http://mxr.mozilla.org/seamonkey/source/layout/printing/nsPrintEngine.cpp#1896
 1896   if (printRangeType == nsIPrintSettings::kRangeSelection &&
 1897       IsThereARangeSelection(mPrt->mCurrentFocusWin)) {
 1898     adjSize.height = NS_UNCONSTRAINEDSIZE;
 1899   }

If I make us jump past this block (leaving adjSize.height at 63360 = 1 page-height, rather than NS_UNCONSTRAINEDSIZE), then we *almost* get correct behavior -- we print the *full lines* that contain the text selection, along with the page headers/footers. (as compared to completely blank pages in current trunk)

Comment 9

[Daniel Holbert [:dholbert]]

Ok, I've determined that the issue is this change from the patch for bug 374050:
 -    aPresContext->DeviceContext()->GetDeviceSurfaceDimensions(width, height);
 +    width = aPresContext->GetPageSize().width;
 +    height = aPresContext->GetPageSize().height;

The old and new code agree on the width.

But in Print-Selection mode, the new code returns NS_UNCONSTRAINEDSIZE for height, and the old code returns 63360.

Comment 10

[Martijn Wargers (dead)]

Isn't this bug 402264 (there is a patch in that bug, that's been bit-rotting)?

Comment 11

[Daniel Holbert [:dholbert]]

(In reply to comment #10)
> Isn't this bug 402264 (there is a patch in that bug, that's been bit-rotting)?

Ah, right you are -- thanks.