828991 - In a page with wide content (triggering shrink-to-fit), "print selection" prints very tiny output, even if the wide stuff isn't selected

Status: NEW

(Core :: Printing: Output, defect)

Description

[Oliver Schoett]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101 Firefox/18.0 SeaMonkey/2.15
Build ID: 20130105222038

Steps to reproduce:

Open text file, select a range of lines, perform "print selection"


Actual results:

Printed pages show header and footer, but blank content area


Expected results:

Printed content area should contain the selected text

Comment 1

[Paul Silaghi, QA [:pauly]]

I confirm the print selection doesn't work on large text files. Nightly 2013-01-14
http://mozqa.com/data/firefox/awesome_bar/diff.txt

Comment 2

[Manuela Muntean [Away]]

This issue is also reproducible with Firefox 19 beta 4 (build ID:20130130080006), on a Mac 10.7.5 OSX machine.

Comment 3

[Manuela Muntean [Away]]

(In reply to Manuela Muntean [:Manuela] [QA] from comment #2)
> This issue is also reproducible with Firefox 19 beta 4 (build
> ID:20130130080006), on a Mac 10.7.5 OSX machine.

I could reproduce it after selecting a text from a .pdf document, using PDF.js.

Comment 4

[u279076]

Is this a regression? Can someone please test previous Firefox versions to find if this ever worked?

Comment 5

[Daniel Holbert [:dholbert]]

I can't reproduce, using Nightly on linux.

Oliver or Paul: Can you try this considerably-simpler text document:
   https://ftp.mozilla.org/pub/mozilla.org/README
and report back if you can reproduce?

(W/ the diff file you posted, I don't get blank output, but I do get really-tiny output, probably because we're doing shrink-to-fit, so that the the longest line of non-breakable text isn't clipped, or something.)

Comment 6

[Paul Silaghi, QA [:pauly]]

(In reply to Daniel Holbert [:dholbert] from comment #5)
> Oliver or Paul: Can you try this considerably-simpler text document:
>    https://ftp.mozilla.org/pub/mozilla.org/README
> and report back if you can reproduce?
Everything's ok here.

> (W/ the diff file you posted, I don't get blank output, but I do get
> really-tiny output, probably because we're doing shrink-to-fit, so that the
> the longest line of non-breakable text isn't clipped, or something.)
You are perfectly right, the output text is so small on Win I probably didn't notice before. But I consider this to be an issue too.


(In reply to Manuela Muntean [:Manuela] [QA] from comment #3)
> I could reproduce it after selecting a text from a .pdf document, using
> PDF.js.
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #4)
> Is this a regression? Can someone please test previous Firefox versions to
> find if this ever worked?
Print Selection doesn't work with pdf.js, unlike the text files. Reproducible on latest nightly 21.0a1 (2013-02-06) and nightly 16.0a1 (2012-06-08), so it wouldn't be a regression. Tested on Win 7 x64.
http://manuals.info.apple.com/en/ipad_user_guide.pdf
http://samplepdf.com/sample.pdf

Comment 7

[Daniel Holbert [:dholbert]]

We actually disabled print selection completely in PDF.js, because it has other issues (bug 830278).  So -- let's not discuss PDF.js further here.  If you'd like to track print-selection not printing correctly there, please split that off into a new bug (though keep in mind it probably won't even be an option in up-to-date nightlies).

Let's keep this bug focused on comment 0, with s/blank content area/tiny text in content area/

Here's a trivial testcase that reproduces this:
===
data:text/html,aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa <br><br>select this line of text, and print selection
===

Comment 8

[Daniel Holbert [:dholbert]]

...though there is a workaround -- uncheck "ignore scaling and shrink to fit page width" in the print dialog.  (That's what it's called on Linux, at least -- it may have a different title on other platforms).

Comment 9

[Paul Silaghi, QA [:pauly]]

Thanks for clearing things up.

Comment 10

[Daniel Holbert [:dholbert]]

Sure! (Also: it looks like the print-selection-not-working-in-pdf.js issue is already known, and it was part of the reason it was disabled there -- see bug 830278 comment 9. So no need to file a separate bug for that. (or if you do, please note it on bug 830278.)

Comment 11

[Paul Silaghi, QA [:pauly]]

(In reply to Daniel Holbert [:dholbert] from comment #10)
> Sure! (Also: it looks like the print-selection-not-working-in-pdf.js issue
> is already known, and it was part of the reason it was disabled there -- see
> bug 830278 comment 9. So no need to file a separate bug for that.
Agreed.

Comment 12

[Oliver Schoett]

It is a regression from Firefox version 17 to 18.  I am using Firefox that is auto-updated on the release channel, and use the "print selection" about once a week (continually since > 6 months ago, always tracking the release version).  So for text files, this was a stable feature.  By the way, I almost never use "shrink to fit", but set a fixed zoom percentage (usually between 20% and 50%), using "print preview" to fit my ASCII charts onto pages the way I want them. 

When the Update from 17 to 18 arrived, the feature had worked the day before with V17, and ceased to work immediately after the update to V18.  A day or so later, SeaMonkey received the corresponding automatic update to version 2.15, and the feature now has the same problem there (but I have used SeaMonkey only in version 2.15 for testing, and cannot say how its behaviour was in previous versions).

Comment 13

[u279076]

Oliver, if this is a regression in Firefox 18, can you please narrow it down to a particular Firefox Nightly 18.0a1 build? Firefox 18 was in Nightly between August 28 and October 8, 2012.

First:
> ftp://ftp.mozilla.org/pub/firefox/nightly/2012/08/2012-08-28-03-05-55-mozilla-central/
Last:
> ftp://ftp.mozilla.org/pub/firefox/nightly/2012/10/2012-10-08-03-17-45-mozilla-central/

Using the mozregression tool often makes this process easier:
http://mozilla.github.com/mozregression/

Comment 14

[Ryan VanderMeulen [:RyanVM]]

Using Dan's testcase and the testcase from comment 1, I can reproduce the insanely small text issue on Windows as far back as Firefox 4. I don't think that should be treated as a regression.

Comment 15

[Oliver Schoett]

I agree it is probably not a regression.  I think the file triggering my original report had some insanely long lines *outside* the selected printing range.  This made the font shrinking a surprise, given that the selected lines were not overlong at all.