402264 - Print Selection prints blank pages

Status: RESOLVED FIXED

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

Description

[Olli Pettay [:smaug][[e-mail]]]

Select something on a page, File->Print, click selection(o), select "Print to file", press print. The result document is empty, on 2007-09-04 build it still contains the selection.

Regression range
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-09-20+02%3A00%3A00&maxdate=2007-09-21+06%3A00%3A00&cvsroot=%2Fcvsroot

Maybe bug 396587 or bug 395449 or Bug 377336

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Backing out Bug 377336 didn't seem to help.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

Backing out Bug 396587 doesn't help either.
So probably cairo update?

Comment 3

[Mats Palmgren (inactive)]

I get a different regression range:  2007-03-20-04 -- 2007-03-21-04
which points to bug 374050.
Backing out the change to layout/generic/nsSimplePageSequence.cpp:
https://bugzilla.mozilla.org/attachment.cgi?id=258658&action=diff#mozilla/layout/generic/nsSimplePageSequence.cpp_sec1
fixes the bug.

In a debugger I see that GetPresContext()->GetPageSize().height
is NS_UNCONSTRAINEDSIZE whereas GetDeviceSurfaceDimensions() returns
a constrained height.

The bug also occurs on MacOSX, but not on Windows XP.

Comment 4

[Mats Palmgren (inactive)]

Attachment: Patch rev. 1

This block is what causes SetPageSize() with an unconstrained height.
Removing it fixes the bug on both Linux and MacOSX and doesn't
cause any problems on Windows AFAICT.
Even printing multi-page selections seems to work.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

I guess we're seeing a different bug, because the patch doesn't fix this bug for me.
I've been testing using http://www.mozilla.org/projects/firefox/3.0a1/firstrun/ and selecting everything in the blueish "Gran Paradiso Alpha 1 Start Page" box and trying to print that selection.

Comment 6

[Mats Palmgren (inactive)]

That's odd, with your STR I get a blank page without the patch and a 
correctly printed page with the patch, so it does fix it for me.

Do you get a different result if you exclude the image and just select
a line of text?

What |height| do you have after this line, with/without the patch:
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/layout/generic/nsSimplePageSequence.cpp&rev=3.157&root=/cvsroot&mark=504#460

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

Sorry, my mistake. I must have tested something wrong. Seems to work now.

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

I mean the patch seems to work.

Comment 9

[Eli Friedman]

Does that patch really work with printing selection on arbitrary pages (i.e. beyond the first)?  If so, it's fine...

Comment 10

[Boris Zbarsky [:bzbarsky]]

Upping priority; I really don't think this is a regression we should be OK with shipping.

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

With the patch can't get the selection printing working beyond the first page.

Comment 12

[Stuart Parmenter]

dholbert: can you work with mats here?  see comment #3

Comment 14

[Daniel Holbert [:dholbert]]

I don't see an option to print the selection at all anymore, using the new GTK print dialog (which was added in bug 193001).

We should probably file a new bug on this.

Michael, how possible (if at all) would it be for us to add a "Print Selection" radio button to the main panel of the GTK print dialog?

Comment 15

[Daniel Holbert [:dholbert]]

Ah -- cancel Comment #14 -- there's a "Print Selection Only" checkbox on the "Options" tab in the Print dialog.

The checkbox is currently grayed out for me (even when I've got text selected), so maybe I'm doing something that's making it disabled...  not sure right now.

Comment 17

[Daniel Holbert [:dholbert]]

(In reply to comment #11)
> With the patch can't get the selection printing working beyond the first page.

I'm also seeing this bug with the posted patch.

Currently, with the patch, I'm seeing this specific behavior when I print a selection:
  If selection is on first page:
   - The selection is printed
   - Any lines that contain selected text are printed in full **
   - Headers/footers are printed
  Else: (selection is after first page)
   - Blank output **

The things marked ** are bugs with the current patch and need to be corrected in the final fix.

Comment 18

[Daniel Holbert [:dholbert]]

Comment on attachment 287280 [details] [diff] [review]
Patch rev. 1

Canceling review-request and obsoleting the first patch, per comments 9 and 17.

Comment 19

[Dave Purdy]

Confirmed this issue using ffox3 b4 on Win XP.  Tried print > select of just one word on a page and received blank pages.

Comment 21

[Daniel Holbert [:dholbert]]

Platform/ OS --> All/All, per comment 19 & duplicate bug 423573.

Comment 22

[Dave Purdy]

Found another duplicate Bug 411787 -- not sure how to mark as duplicate.  

Recommend change subject of this bug to 'Print Selection prints blank pages in all OS's'

Comment 24

[Martijn Wargers (dead)]

(In reply to comment #22)
> Found another duplicate Bug 411787 -- not sure how to mark as duplicate.  

You need bugzilla privileges to be able to do that. Usually, you might want to apply for those, if you have considerable experience with bugzilla and do "the right thing" in bugzilla. See also http://www.mozilla.org/quality/help/bugzilla-privilege-guide.html

Comment 26

[Daniel Holbert [:dholbert]]

Mats, mind if i steal this bug from you?

Comment 27

[Mats Palmgren (inactive)]

No problem.

Comment 28

[d]

beta 4 printed blank pages. beta 5 prints part of the selection (the first page, not fully).
is it because the "multiple selection" feature?
will it be fixed before the release?

Comment 29

[Daniel Holbert [:dholbert]]

(In reply to comment #28)
> beta 4 printed blank pages. beta 5 prints part of the selection (the first
> page, not fully).
> is it because the "multiple selection" feature?

Not sure what you mean by that... perhaps I'm not familiar with that feature?

> will it be fixed before the release?

Yup, I'll make sure to have this fixed by final release.  (I think that's the definition of Priority=P2 & blocking1.9+, btw -- needs fixing by final release)

Comment 30

[Daniel Holbert [:dholbert]]

(In reply to comment #29)
> (In reply to comment #28)
> > beta 4 printed blank pages. beta 5 prints part of the selection (the first
> > page, not fully).
> > is it because the "multiple selection" feature?
> 
> Not sure what you mean by that... perhaps I'm not familiar with that feature?

Oh, crazy -- do you mean how you can hold "Ctrl" and then select multiple chunks of text at once?  I didn't know about that until now! That's awesome! :)

Anyway, if that was added between B4 and B5, then it's entirely likely that this bug was partially fixed by the addition of that feature.

Comment 31

[d]

maybe it caused the bug in b4,
and some patch between b4 and b5 caused the new bug in b5
(the printing on part of one page of the selection)

Comment 32

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Here's a testcase to use.

Testing latest-nightly:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008040704 Minefield/3.0pre

Note that there are three lines here:

  Text at the beginning
  Filler                  [<--- in a div that extends off the page]
  
  Text at the end
  
If I highlight part of any one line and then print selection, then that full line is printed.  This is true even for "Text at the end", so it seems that we're ok to print selections on non-first pages.

However, if I select multiple lines from this testcase, only the first selected line is printed.

Also, I'm not seeing any headers / footers being printed right now, when I print selection.

Comment 33

[Daniel Holbert [:dholbert]]

Attachment: testcase 2

If I select-all on this second testcase and print with "Print Selection Only" checked, the output shows just the first line and the very top of the second line.

Comment 34

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 Print-To-PDF output (with select-all)

Comment 35

[Daniel Holbert [:dholbert]]

(In reply to comment #32)
> However, if I select multiple lines from this testcase, only the first selected
> line is printed.
(In reply to comment #33)
> If I select-all on this second testcase and print with "Print Selection Only"
> checked, the output shows just the first line and the very top of the second
> line.

I don't actually see these issues anymore, using latest-nightly.

Headers/footers are still missing in print-selection, though I don't consider that a huge issue.

And I still get blank output when printing this URL, from bug 420488, with "Shop templates" and the tables below it selected (though I have a fix for this):
http://www.oxid-esales.com/de/documentation_files/Template_documentation_30_English/index.html

Comment 36

[Daniel Holbert [:dholbert]]

Attachment: testcase 3 (w/ 7-inch-wide div)

This testcase is reduced from the "oxid-esales.com" URL from my previous comment.  Print-Selection (with select-all) prints blank pages in latest-trunk.

Comment 37

[Daniel Holbert [:dholbert]]

Attachment: testcase 4 (w/ 20-inch-wide div) (still broken: see bug 428109)

This is the same as testcase 3, but with a much wider div.  It also prints blank pages in latest-trunk, using select-all and print-selection.

Comment 38

[Daniel Holbert [:dholbert]]

Attachment: patch v2

This patch fixes testcase 3, and it gives us some printed output on the oxid-esales site.

It also fixes these invalid height errors I was seeing on both testcase 3 and on the oxid-esales site:

###!!! ASSERTION: bad height: 'Not Reached', file /scratch/work/builds/trunk.08-04-09.09-08/mozilla/layout/generic/nsLineLayout.cpp, line 187
Block(body)(1)@0x945895c: Init: bad caller: height WAS 1092049184(0x41175920)


It also fixes this warning that I previously saw in testcase 4:
WARNING: Reflow aborted; no space for content: file /scratch/work/builds/trunk.08-04-09.09-08/mozilla/layout/generic/nsPageFrame.cpp, line 122

Testcase 4 still prints blank pages, though, as described in previous comment.

Comment 39

[Daniel Holbert [:dholbert]]

(In reply to comment #38)
> This patch fixes testcase 3, and it gives us some printed output on the
> oxid-esales site.

To clarify this a bit -- it doesn't completely fix the oxid-esales site.  It *does* give us some printed content there, but the content is shifted up a bit, with the very top being clipped off at the top of the page.

Comment 40

[Daniel Holbert [:dholbert]]

(In reply to comment #38)
> It also fixes this warning that I previously saw in testcase 4:
> WARNING: Reflow aborted; no space for content: file
> /scratch/work/builds/trunk.08-04-09.09-08/mozilla/layout/generic/nsPageFrame.cpp,
> line 122

Haha... wow.  We were hitting that warning because 'scale' is 0.34 in that testcase, and so we ended up overflowing into negative values at nsPageFrame.cpp:114 :

(original code)  maxSize.height = NSToCoordCeil(maxSize.height / scale);
(substituting)   maxSize.height = NSToCoordCeil(nscoord_MAX / 0.34)
(result)         maxSize.height = -2147483648

which explains why we entered an "if (... || maxSize.height < onePixelInTwips)" clause and triggered this warning.

Anyway, patch v2 avoids this nastiness.

Comment 41

[Daniel Holbert [:dholbert]]

(In reply to comment #37)
> Created an attachment (id=314639) [details]
> testcase 4 (w/ 20-inch-wide div)
(In reply to comment #38)
> Testcase 4 still prints blank pages, though, as described in previous comment.
> 

Actually, testcase 4 isn't really a regression -- if you increase the width to be even larger (e.g. 40in), then FF2 prints blank pages as well, for the same underlying reason, I'm pretty sure.

So basically, in FF3, there's a lower threshhold for that bug to start occurring, but it's still a bug that was in FF2.  And in FF3 *and* FF2, this requires widths much larger than the width of a page, so I'm not too worried about it, and I'll file a new non-blocking bug for it.

Comment 42

[Daniel Holbert [:dholbert]]

Comment on attachment 314642 [details] [diff] [review]
patch v2

Trivial patch -- just inserts check to prevent us from scaling up an unconstrained available height.

Comment 43

[Daniel Holbert [:dholbert]]

(In reply to comment #41)
> I'll file a new non-blocking bug for it.

Filed bug 428109 for testcase 4.

Comment 44

[d]

it still prints only the first page.
for example, select all in http://www.mozilla.org/projects/ and print the selection.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008040907 Minefield/3.0pre

Comment 45

[Daniel Holbert [:dholbert]]

(In reply to comment #44)

Yeah, that's a limitation with our current implementation.  According to MXR blame, it's been that way since 2002.

See this chunk of code:

1934   // XXX - Hack Alert
1935   // OK, so there is a selection, we will print the entire selection
1936   // on one page and then crop the page.
1937   // This means you can never print any selection that is longer than
1938   // one page put it keeps it from page breaking in the middle of your
1939   // print of the selection (see also nsSimplePageSequence.cpp)

http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/layout/printing/nsPrintEngine.cpp&rev=1.174#1934

Comment 46

[Rimas Kudelis [use needinfo to ping]]

Hm.... isn't it possible to join all selects first, and break the result into pages then?

Comment 47

[d]

It is possible to print selection on more than one page in 2.0.

Comment 48

[Daniel Holbert [:dholbert]]

Comment on attachment 314642 [details] [diff] [review]
patch v2

Requesting approval1.9 on patch v2.

 - Fixes a clear case where we need to check for unconstrained size before doing arithmetic. (more in comment 42 and comment 40)

 - Risk = little to none

 - Finishes off this bug's "prints blank pages" issue.  (aside from the non-regression part that remains in bug 428109.)

Comment 49

[d]

Attachment: multi page selection print

this pdf proves that
Mozilla/5.0 (Windows; U; Windows NT 5.1; he-IL; rv:1.8.1.9) Gecko/20071030 SeaMonkey/1.1.6
can print multiple-page selection.

Comment 50

[Daniel Holbert [:dholbert]]

(In reply to comment #47)
> It is possible to print selection on more than one page in 2.0.
(In reply to comment #49)
> Created an attachment (id=314869) [details]

Ok, I stand corrected RE comment 45. (though I wonder why that comment was never removed from the code)

Filed bug 428339 for the "Print Selection output is limited to one page" issue.

Comment 51

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Comment on attachment 314642 [details] [diff] [review]
patch v2

Approval not needed, blocking P2 bug.

Comment 52

[Daniel Holbert [:dholbert]]

Comment on attachment 314642 [details] [diff] [review]
patch v2

Shaver's silly and forgot that  http://wiki.mozilla.org/TreeStatus currently says I need approval to land.

Re-requesting approval, per IRC conversation.

Comment 53

[Damon Sicore (:damons)]

Comment on attachment 314642 [details] [diff] [review]
patch v2

a1.9+=damons

Comment 54

[Daniel Holbert [:dholbert]]

Patch 314642 checked in. --> FIXED

I'll file a follow-up bug for the remaining positioning issue on the oxid-esales site from comment 39.

Comment 55

[Daniel Holbert [:dholbert]]

(In reply to comment #54)
> I'll file a follow-up bug for the remaining positioning issue on the
> oxid-esales site from comment 39.
> 

Filed bug 428417 for this.

Comment 56

[mdew]

did this patch make it into -rc1?

Comment 57

[Daniel Holbert [:dholbert]]

Yes, it did.

Comment 58

[Hideo Oshima]

After checking the patch in, printing to file is OK.
The file contains only selected area.
But in the case of printing to printer, whole page which contains selected area
is printed out.
Am I something wrong?

I use Firefox trunk on Linux.

Comment 59

[Hideo Oshima]

(In reply to comment #58)
> After checking the patch in, printing to file is OK.
> The file contains only selected area.
> But in the case of printing to printer, whole page which contains selected area
> is printed out.
> Am I something wrong?
> 
> I use Firefox trunk on Linux.
 
I made a mistake.
In the case of printing to printer, nothing is printed out.
I am sorry for wrong report.

Comment 60

[Daniel Holbert [:dholbert]]

(In reply to comment #58 and comment #59)
I don't see either of these issues (blank pages or full pages).

Can you post more detail about what you're doing to get this outcome?

e.g., with latest-trunk (2008041104) on Linux, I just did this:
 - Open testcase 2 (attachment 314434 [details])
 - Select second line of text
 - Print, with "Print Selection Only" checked
That worked for me -- only the second line was printed.
I tried various tests on testcase 1, too, all of which worked for me.

Comment 61

[Hideo Oshima]

(In reply to comment #60)
> (In reply to comment #58 and comment #59)
> I don't see either of these issues (blank pages or full pages).
> 
> Can you post more detail about what you're doing to get this outcome?
> 
> e.g., with latest-trunk (2008041104) on Linux, I just did this:
>  - Open testcase 2 (attachment 314434 [details])
>  - Select second line of text
>  - Print, with "Print Selection Only" checked
> That worked for me -- only the second line was printed.
> I tried various tests on testcase 1, too, all of which worked for me.

I tested according to your advice.
Nothing was still output.

My environtment:
Debian GNU/Linux unstable
CUPS 1.3.7-1
GTK+ 2.14.1-1

Comment 62

[Hideo Oshima]

Attachment: CUPS log for the test according to comment 60

I attach a CUPS log of testing testcase 2.

Comment 63

[Gabriele Best [:Gabri]]

Firefox 3 last nightly doesn't print yet.

Comment 64

[mdew]

confirmed, this isn't resolved. print selection prints blank pages in the latest Nightly.


Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008041212 Firefox/2.0b2

Comment 65

[Daniel Holbert [:dholbert]]

Ok -- I still can't reproduce, but reopening pending more investigation / fixing.

Comment 66

[:Gavin Sharp [email: [e-mail]]]

It would be best to file a new bug if the patch that landed won't be backed out (I assume it fixed at least one of the instance of this bug, the one that dholbert could reproduce). Dealing with multiple patches per bug is a recipe for disaster.

Comment 67

[Daniel Holbert [:dholbert]]

(In reply to comment #66)
> It would be best to file a new bug if the patch that landed won't be backed out

Ok, filed Bug 428975 for any remaining "print selection prints blank pages" issues.  Please direct further discussion there.  Re-closing this bug.

> (I assume it fixed at least one of the instance of this bug, the one that
> dholbert could reproduce).

(Yup, it did)

Comment 68

[Gabriele Best [:Gabri]]

THIS BUG WASN'T FIXED!
FF3.0pre DON'T PRINT ANYTHING!

Comment 69

[Martijn Wargers (dead)]

Mrtb, on what site(s) does Firefox3 not print anything?

Comment 70

[Gabriele Best [:Gabri]]

Attachment: Example File

Comment 71

[Gabriele Best [:Gabri]]

I've attached an example file.

To see the bug open it and:
1.Select from the first row to the 80th one;
2.Click on File->Print and then select "Selection" radio button; 
3.Click on ok;
4.See that Header and Footer weren't printed, rows from 1 to 49 were printed, rows from 50 to 80 not.

Sometimes it doesn't print anything.

Comment 72

[Martijn Wargers (dead)]

Thanks for the testcase, Mrtb. I can indeed reproduce it with your testcase and the steps to reproduce. And it isn't a problem on branch.

It's best to file a new bug on this issue, because reopening this bug at this point would only increase confusion. If you do file a new bug, please mention the bug number here.

Comment 73

[Gabriele Best [:Gabri]]

I've opened a new bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=429330

Comment 75

[Jeff Wolski]

Using FF3.0RC1


1. navigate to http://www.mozilla.com/en-US/firefox/?from=getfirefox
2. select 1st paragraph of text beginning "The award-winning Web browser..."
3. Click on File->Print and then select "Selection" radio button; 
3. Click on ok;
4. The paragraph prints fine.
5. select the last paragraph of text beginning "Choose from over a thousand useful add-ons..."
6. Click on File->Print and then select "Selection" radio button; 
7. Click on ok;
8. a BLANK page prints

When I use the test cases 1 and 2, the text prints just fine.  When I use any text further down a web page, I get a blank sheet.

Comment 76

[Daniel Holbert [:dholbert]]

(In reply to comment #75)
I'm pretty sure that's bug 433373.

Comment 77

[mojohdk]

Hello sorry if this is useless or unclear. This is my 1st report and I see that the current status is resolved/fixed. Yet I am on windows XP, using FF3RC1 and still seeing this bug (it's not happening with FF2)

My test case is the page at http://beust.com/weblog/archives/000483.html
If you select the case from under the jedi picture up to the end of the blog post (before the comments), only a chunk of the selection appears on the printout. The problem is worse when printing double-sided or in booklet format with the contents being clipped and overwriting the page header. I'd swear that prior to the RC, the printed output (at least when using "booklet printing") was actually empty (except for a 1st page header, but I just upgraded to FF3RC to check whether the problem still existed). It all behaves as expected with FF 2.0.0.12

Comment 78

[Daniel Holbert [:dholbert]]

(In reply to comment #77)
> with the contents being clipped and overwriting the page header.

That's bug 433373.

Comment 79

[Ian P]

I just downloaded FF 3.03+ on May 26th 2008.  My printer is failing to print selected text using FF3.  However it will print a selected page.  For example: Print-Print Range-Pages-2 to 2.  I'm a Win XP user.