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
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
Status: UNCONFIRMED → NEW
Component: Untriaged → Printing: Output
Ever confirmed: true
Product: Firefox → Core
Version: 18 Branch → Trunk
This issue is also reproducible with Firefox 19 beta 4 (build ID:20130130080006), on a Mac 10.7.5 OSX machine.
(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.
Is this a regression? Can someone please test previous Firefox versions to find if this ever worked?
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.)
(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
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 ===
Summary: "print selection" prints page with header/footers and blank content → In a page with wide content (triggering shrink-to-fit), "print selection" prints very tiny output, even if the wide stuff isn't selected
...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).
Thanks for clearing things up.
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.)
(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.
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).
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/
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.
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.
You need to log in before you can comment on or make changes to this bug.