Closed Bug 402264 Opened 14 years ago Closed 13 years ago
Print Selection prints blank pages
204 bytes, text/html
71 bytes, text/html
7.83 KB, application/pdf
167 bytes, text/html
168 bytes, text/html
1.37 KB, patch
|Details | Diff | Splinter Review|
67.44 KB, application/download
15.52 KB, text/plain
1.36 KB, text/html
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
Backing out Bug 377336 didn't seem to help.
Backing out Bug 396587 doesn't help either. So probably cairo update?
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.
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.
Assignee: nobody → mats.palmgren
Status: NEW → ASSIGNED
Attachment #287280 - Flags: review?(sharparrow1)
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.
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
Sorry, my mistake. I must have tested something wrong. Seems to work now.
I mean the patch seems to work.
Does that patch really work with printing selection on arbitrary pages (i.e. beyond the first)? If so, it's fine...
Flags: blocking1.9? → blocking1.9+
Priority: -- → P3
Target Milestone: --- → mozilla1.9 M10
Upping priority; I really don't think this is a regression we should be OK with shipping.
Priority: P3 → P2
With the patch can't get the selection printing working beyond the first page.
dholbert: can you work with mats here? see comment #3
Flags: tracking1.9+ → blocking1.9+
Target Milestone: mozilla1.9beta2 → ---
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?
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.
(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 on attachment 287280 [details] [diff] [review] Patch rev. 1 Canceling review-request and obsoleting the first patch, per comments 9 and 17.
Confirmed this issue using ffox3 b4 on Win XP. Tried print > select of just one word on a page and received blank pages.
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'
(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
Summary: Printing selection is broken in Linux/trunk → Print Selection prints blank pages
Mats, mind if i steal this bug from you?
Assignee: mats.palmgren → dholbert
Status: ASSIGNED → NEW
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?
(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)
(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.
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)
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.
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.
Attachment #314435 - Attachment description: testcase 2 Print-To-PDF output (select all) → testcase 2 Print-To-PDF output (with select-all)
(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
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.
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.
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.
(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.
(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.
(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 on attachment 314642 [details] [diff] [review] patch v2 Trivial patch -- just inserts check to prevent us from scaling up an unconstrained available height.
(In reply to comment #41) > I'll file a new non-blocking bug for it. Filed bug 428109 for testcase 4.
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
(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
Hm.... isn't it possible to join all selects first, and break the result into pages then?
It is possible to print selection on more than one page in 2.0.
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.)
this pdf proves that Mozilla/5.0 (Windows; U; Windows NT 5.1; he-IL; rv:22.214.171.124) Gecko/20071030 SeaMonkey/1.1.6 can print multiple-page selection.
(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 on attachment 314642 [details] [diff] [review] patch v2 Approval not needed, blocking P2 bug.
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 on attachment 314642 [details] [diff] [review] patch v2 a1.9+=damons
Attachment #314642 - Flags: approval1.9? → approval1.9+
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.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Attachment #314639 - Attachment description: testcase 4 (w/ 20-inch-wide div) → testcase 4 (w/ 20-inch-wide div) (still broken: see bug 428109)
(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.
did this patch make it into -rc1?
Yes, it did.
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.
(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.
Attachment #314216 - Attachment description: testcase → testcase 1
(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.
(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
I attach a CUPS log of testing testcase 2.
Firefox 3 last nightly doesn't print yet.
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
Ok -- I still can't reproduce, but reopening pending more investigation / fixing.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
(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)
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → FIXED
THIS BUG WASN'T FIXED! FF3.0pre DON'T PRINT ANYTHING!
Mrtb, on what site(s) does Firefox3 not print anything?
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.
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.
I've opened a new bug. https://bugzilla.mozilla.org/show_bug.cgi?id=429330
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.
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 126.96.36.199
(In reply to comment #77) > with the contents being clipped and overwriting the page header. That's bug 433373.
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.
You need to log in before you can comment on or make changes to this bug.