Closed Bug 1003707 Opened 6 years ago Closed 6 years ago

pdf.js print prints a white page

Categories

(Core :: Graphics: Layers, defect, major)

29 Branch
x86_64
All
defect
Not set
major

Tracking

()

VERIFIED FIXED
mozilla32
Tracking Status
firefox29 + verified
firefox30 + verified
firefox31 --- verified
firefox32 --- verified
b2g-v1.4 --- fixed
b2g-v2.0 --- fixed

People

(Reporter: borut, Assigned: mattwoodrow)

References

Details

(Keywords: regression, Whiteboard: [pdfjs-d-printing] [qa!])

Attachments

(4 files, 1 obsolete file)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20140421221237

Steps to reproduce:

Open the PDF file and print from the built-in PDF browser.


Actual results:

Prints a blank sheet.


Expected results:

Should Print Download as previous versions.
Summary: not print → pdf.js print prints a white page
Severity: normal → critical
Please fix or remove built in pdf brovser. Please release fixed firefox version 29.0.1.
Is this a regression since Firefox 29? In other words? Was Firefox 28 unaffected?
Component: Untriaged → PDF Viewer
(In reply to Masatoshi Kimura [:emk] from comment #2)
> Is this a regression since Firefox 29? In other words? Was Firefox 28
> unaffected?

In Firefox 28 is good. After installing version 29 is the error as described above.
Confirmed. A virtual printer drier was enough to reproduce the issue.
Status: UNCONFIRMED → NEW
Ever confirmed: true
So we are talking about 64bit version of Firefox for Windows. Can you replicate that on 32bit version?
Severity: critical → normal
Flags: needinfo?(borut)
Do I have to install 32-bit Windows only to confirm?
(In reply to Yury Delendik (:yury) from comment #5)
> So we are talking about 64bit version of Firefox for Windows.

No, I confirmed it with a 32-bit version of Firefox 29 on 64-bit version of Windows which "WOW64" means.
64-bit versions of Firefox will have "Win64" in the user-agent.
Flags: needinfo?(borut)
Severity: normal → major
Please rapid improvement in error. I can easily view and print PDF documents.
Please rapid improvement in error. You can not easily view and print PDF documents.
I can reproduce in Firefox29 and Beta30b1candidate
But, I cannot reproduce in Aurora31.0a1 and Nightly32.0a2.


Regression window(beta)
Good:
https://hg.mozilla.org/releases/mozilla-beta/rev/3437e5663d9e
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 ID:20140414130500
Bad:
https://hg.mozilla.org/releases/mozilla-beta/rev/c8f1a4f5ca4d
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 ID:20140415102658
Pushlog:
http://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=3437e5663d9e&tochange=c8f1a4f5ca4d

Regression window(aurora)
Good:
https://hg.mozilla.org/releases/mozilla-aurora/rev/f14047fa8d63
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 ID:20140415004003
Bad:
https://hg.mozilla.org/releases/mozilla-aurora/rev/3be2814c6897
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 ID:20140415102202
Pushlog:
http://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=f14047fa8d63&tochange=3be2814c6897


Suspect— Bug 991767 - Use Moz2D for printing surfaces. r=roc, a=sledru


I cannot determine regression window for m-c and m-i, because browser crashes before landing Bug 991767.
(m-c)
Crash:
https://hg.mozilla.org/mozilla-central/rev/5405d6f4e3c6
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0 ID:20140406100625
Fixed crash:
https://hg.mozilla.org/mozilla-central/rev/e2db1c06a933
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0 ID:20140407043727
Pushlog(fixed crash)
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5405d6f4e3c6&tochange=e2db1c06a933

(m-i)
Crash:
https://hg.mozilla.org/integration/mozilla-inbound/rev/b9085d8ca22e
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0 ID:20140406200125
Fixed crash:
https://hg.mozilla.org/integration/mozilla-inbound/rev/7248b992c6b2
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0 ID:20140406210825
Pushlog(fixed crash)
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=b9085d8ca22e&tochange=7248b992c6b2
I can confirm it's a regression due to bug 991767 patch:

The first bad revision is:
changeset:   184764:55422890fb8f
user:        Matt Woodrow <mwoodrow@mozilla.com>
date:        Mon Apr 07 16:07:12 2014 +1200
summary:     Bug 991767 - Use Moz2D for printing surfaces. r=roc, a=sledru
Blocks: 991767
Component: PDF Viewer → Graphics: Layers
Product: Firefox → Core
Whiteboard: [pdfjs-d-printing]
Duplicate of this bug: 999284
Duplicate of this bug: 1004150
I'd like more information on why this cannot be reproduced on 31/32 -  Matt, any ideas?  Do we have a potential forward fix?  What would be the user impact of backing out bug 991767?
Flags: needinfo?(matt.woodrow)
Assignee: nobody → matt.woodrow
(In reply to Lukas Blakk [:lsblakk] from comment #15)
> I'd like more information on why this cannot be reproduced on 31/32 -  Matt,
> any ideas?  Do we have a potential forward fix?  What would be the user
> impact of backing out bug 991767?

Well, we uplifted it because it fixed bug 740325, a topcrasher. Backing it out would reintroduce that again.

I'll see if I can figure out what changed in 31/32 so that everything works.
Flags: needinfo?(matt.woodrow)
We are seeing what appears to be this same bug on our Ubuntu Linux workstations.
Ubuntu 12.0.4.4 LTS, and Firefox 29.0+build1-0ubuntu0.12.04.2
That firefox version was taken by the automatic updater and now we get lots of blank pages from the printers in our computer labs.
Yes, this fix was for a pretty huge crasher.

That said, why did we uplift this to beta? The comments in the crasher bug only talk about the crash being bad on 30 and 31, not about 29...
Hrm, the actual patch was in bug 991767 (and I was looking at bug 740325 which was the really bad topcrasher on 30 and 31), but also there it's pretty unclear as to why exactly we uplifted this to beta as there's no evidence in the bug that the crash in question even happened with 29 in the first place. :(
Duplicate of this bug: 1004385
The topcrasher doesn't actually exist on 29, so backing out from there would be fine.

For 30 we need to find a solution.

I'm fairly sure this works on 31/32 because of http://hg.mozilla.org/integration/mozilla-inbound/rev/25306d89bded

Haven't figured out exactly why it doesn't work currently though. I also can't reproduce the same issue on OSX.
Urgh, figured it out.

http://mxr.mozilla.org/mozilla-beta/source/gfx/2d/DrawTargetCairo.cpp#122

We take that branch for CAIRO_SURFACE_TYPE_WIN32_PRINTING, but cairo will just return 0 for printing surfaces. Sigh.
Attached patch One idea (obsolete) — Splinter Review
Bas, what do you think about doing this? Having mSize on NativeSurface is a bit weird if d2d won't use it but maybe that's ok.

GetCairoSurfaceSize has caused issues before, and it's broken for quartz printing surfaces too.

We should also get rid of CreateSourceSurfaceForCairoSurface (since it's basically a clone of the native surface one) and then that size guessing function can go away entirely.
Attachment #8416341 - Flags: feedback?(bas)
Duplicate of this bug: 1005188
Duplicate of this bug: 1005192
I presume this bug will not be like https://bugzilla.mozilla.org/show_bug.cgi?id=776608 thats been open for around a year.

If Firefox is to have a 29.0.0.1 release can I suggest that PDF Printing be fixed
Attachment #8416341 - Attachment is obsolete: true
Attachment #8416341 - Flags: feedback?(bas)
Attachment #8417932 - Flags: review?(bas)
Duplicate of this bug: 1006649
Duplicate of this bug: 1006672
Verified as fixed using the following environment:

FF 29.0.1
Build Id: 20140506152807
User Agent:Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0
Os: Win 7 x64
Problem seems to only be with the plugin, not with opening it in Adobe Reader or Acrobat and then printing it. Hoping for a fix soon.
Firefox 30 beta 2 have this same problem. :/
(In reply to l.borowka from comment #33)
> Firefox 30 beta 2 have this same problem. :/

Yes, there is no fix for the issue yet - we just backed out the patch that caused it from release. As far as I can tell, we're hoping to fix the issue properly on beta.
Attachment #8417932 - Flags: review?(bas) → review+
https://hg.mozilla.org/mozilla-central/rev/3b5fb4abaa3f
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
Duplicate of this bug: 1007672
Can this be tested by an automated test?
Flags: in-testsuite?
(In reply to Henrik Skupin (:whimboo) from comment #38)
> Can this be tested by an automated test?

I don't think so.

The bug was specific to GDI printing surfaces, which we can't use in any of our existing test suites.

We'd need a new suite/harness that actually prints (probably to a virtual printer) and then verifies that output.
Flags: in-testsuite? → in-testsuite-
Whiteboard: [pdfjs-d-printing] → [pdfjs-d-printing] [qa+]
Then I think we should have at least a moztrap test for now to cover that. Maybe we can collect different URLs in that test which were known to cause problems in printing.
Flags: in-moztrap?(mihaela.velimiroviciu)
Created Moztrap test: https://moztrap.mozilla.org/manage/case/12971/
Flags: in-moztrap?(mihaela.velimiroviciu) → in-moztrap+
The issue also occurs here on a computer equipped with Ubuntu Trusty Tahr 64 bit and Windows 7 32 bit. I can test by only "printing as pdf". 
That will also give blank output.
Thank you for the correction. Version 29.0.1 already prints normally. Version 30 b3 still does not print, and I hope that it does not release a version of the official 30 without improving the empty print.
(In reply to Matt Woodrow (:mattwoodrow) from comment #35)
> https://hg.mozilla.org/integration/mozilla-inbound/rev/3b5fb4abaa3f

Matt, can you get this landed on beta?
I am using the Arch package firefox-29.0.1-1 (built 2014-05-09T12:31:49 PDT) and the bug is still present, so I don't understand why it's been marked RESOLVED FIXED.
(In reply to Vladimir G. Ivanovic from comment #45)
> I am using the Arch package firefox-29.0.1-1 (built 2014-05-09T12:31:49 PDT)
> and the bug is still present, so I don't understand why it's been marked
> RESOLVED FIXED.

We mark bugs as resolved once they are fixed on mozilla-cental (firefox 32 currently).

That said, 29.0.1 should have this bug fixed.
Comment on attachment 8417932 [details] [diff] [review]
Pass surface sizes in

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Bug 991767
User impact if declined: Broken printing 
Testing completed (on m-c, etc.): Been on m-c for a week or so.
Risk to taking this patch (and alternatives if risky):
It's not an entirely trivial change, but getting it onto beta ASAP should give us the best chance of finding any regressions.

One alternative is to uplift bug 989858 instead, but that has already had a few regressions and we'd need to uplift the whole set of fixes.

We could also just backout and live with bug 740325.

String or IDL/UUID changes made by this patch: None.
Attachment #8417932 - Flags: approval-mozilla-beta?
Attachment #8417932 - Flags: approval-mozilla-aurora?
Comment on attachment 8417932 [details] [diff] [review]
Pass surface sizes in

Approving also for beta since it is "early" in the process (beta 4). This will give us time to fix other regression or backout this patch if needed.
Attachment #8417932 - Flags: approval-mozilla-beta?
Attachment #8417932 - Flags: approval-mozilla-beta+
Attachment #8417932 - Flags: approval-mozilla-aurora?
Attachment #8417932 - Flags: approval-mozilla-aurora+
Hello, 

Today I noticed that the version 29.0.1 prints, but also releases the second page blank. I do not know why this is happening. In the preview I have one page, and come to me two cards (one correct, one blank).
Here too we get one blank page. Strange.
(In reply to l.borowka from comment #49)
> Today I noticed that the version 29.0.1 prints, but also releases the second
> page blank. I do not know why this is happening. In the preview I have one
> page, and come to me two cards (one correct, one blank).

Please raise that as a separate bug, it might be a completely separate issue and for sure is a different symptom in both severity and what it actually does than the one we solved here.
(In reply to l.borowka from comment #49)
> Hello, 
> 
> Today I noticed that the version 29.0.1 prints, but also releases the second
> page blank. I do not know why this is happening. In the preview I have one
> page, and come to me two cards (one correct, one blank).

Template File print one blank page:
http://www.sendspace.pl/file/7f70845ad58aa9006efa8f4
This needs rebasing for beta.
Flags: needinfo?(matt.woodrow)
Depends on: 1008610
Kairo, should this stay resolved, and we file a new bug with the new crash stack (though the same signature)?
Flags: needinfo?(kairo)
whoops, right comment, wrong tab/bug.
Flags: needinfo?(kairo)
Flags: needinfo?(matt.woodrow)
Verified fixed 32.0a1 (2014-05-12), Win 7 x64
Status: RESOLVED → VERIFIED
Should this problem have been fixed on Firefox 30b4?  For me, I still get white pages when printing.
I have just upgraded to Firefox 29.0.1, clicking "upgrade" says that I have the latest.
I am using newly installed Adobe Acrobat Standard v8.0 upgraded to v8.1.6

The page(http://www.sudoku.org.uk/Puzzles/Sudoku.asp) requires (installed) Flash v13.
Clicking on the print button, I go through the normal process of selecting a printer, including specifying a directory & file name. Although the page displays as expected, a blank page is created in the target file, no errors are display, as displayed by the local Acrobat Reader, also v8.1.6.

Do the same thing in IE v11.0.9600.17107 and the page is printed out as expected.
All Adobe items in Firefox/Options are set to use "Adobe Acrobat v8.1" in place of "use Adobe Acrobat in Firefox".
I verified the bug using the following environment:

FF 30.0b5
Build Id: 20140515140857
Os: Win 7 x64

The bug is still reproducible on beta.
https://hg.mozilla.org/mozilla-central/rev/3b5fb4abaa3f has messed up the apperance when using skia on powerpc (a big endian platform).  See https://bugzilla.mozilla.org/attachment.cgi?id=8424358  I also see the text in URL auto-complete drop down and tab headers drawing on top of each other.  These issues seem to be introduced with 3b5fb4abaa3f though I have the patch in bug 1005535 to applied to compile with skia on this platform.  These issues don't show up when  gfx.content.azure.backends=canvas or in 52f249e906ce.
29.0.1 fixed the "empty printed pages" but created another problem.

Steps to reproduce
1. create a new FF profile
2. open http://www.tmoshavim.org.il/uploadimages/2014Temps.pdf 
3. print 
4. The result - all the hebrew characters are printed as empty squares (the numeric charecters are printed ok)

This is another Hebrew Text pdf but this one was printed OK.
http://www.halavi.org.il/info/profesional/prof1/abram-mcont_hahliba_cgorm_lshlmot_hahliba_vebriaot_haetin.pdf

Installing "PDF Viewer" 0.8.1334 addon fixes the problem.
https://addons.mozilla.org/en-US/firefox/addon/pdfjs/

After uninstallig or disabling this addon the problem DOES NOT "return" (the print is ok).

Tested on a new FF profile (no addon)
Firefox 29.0.1
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101
Windows 7 x64
Brother MFC-7360N Printer
(In reply to LL25255252 from comment #66)
> 29.0.1 fixed the "empty printed pages" but created another problem.
> 
> Steps to reproduce
> 1. create a new FF profile
> 2. open http://www.tmoshavim.org.il/uploadimages/2014Temps.pdf 
> 3. print 
> 4. The result - all the hebrew characters are printed as empty squares (the
> numeric charecters are printed ok)
> 
> This is another Hebrew Text pdf but this one was printed OK.
> http://www.halavi.org.il/info/profesional/prof1/abram-
> mcont_hahliba_cgorm_lshlmot_hahliba_vebriaot_haetin.pdf
> 
> Installing "PDF Viewer" 0.8.1334 addon fixes the problem.
> https://addons.mozilla.org/en-US/firefox/addon/pdfjs/
> 
> After uninstallig or disabling this addon the problem DOES NOT "return" (the
> print is ok).
> 
> Tested on a new FF profile (no addon)
> Firefox 29.0.1
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101
> Windows 7 x64
> Brother MFC-7360N Printer

One issue per bug please. File a new one and mark it as blocking this one.
I've opened Bug 1012444 ( Firefox 29.0.1 built-in PDF viewer doesn't print correctly some PDF files).
Thank you @Cork.
Matt - what's missing for this on Beta?  Have you got a follow up fix coming here for branches?
Flags: needinfo?(matt.woodrow)
(In reply to Lukas Blakk [:lsblakk] from comment #69)
> Matt - what's missing for this on Beta?  Have you got a follow up fix coming
> here for branches?

It should have been fixed on beta, the patch has been uplifted.
Flags: needinfo?(matt.woodrow)
(In reply to Matt Woodrow (:mattwoodrow) from comment #70)
> (In reply to Lukas Blakk [:lsblakk] from comment #69)
> > Matt - what's missing for this on Beta?  Have you got a follow up fix coming
> > here for branches?
> 
> It should have been fixed on beta, the patch has been uplifted.

Comment 64 appears to disagree with that, unfortunately
Tracy - can you repro still on Beta?  It seems odd that this wouldn't be working on 30 while it did fix the issue on 29.
Flags: needinfo?(twalker)
(In reply to Lukas Blakk [:lsblakk] from comment #72)
> Tracy - can you repro still on Beta?  It seems odd that this wouldn't be
> working on 30 while it did fix the issue on 29.
I confirm it's fixed in 29.0.1, but not in 30b5
http://www.energy.umich.edu/sites/default/files/pdf-sample.pdf
Flags: needinfo?(twalker)
So...is there something about the test pdf in comment 73 that is causing special behaviour, or something missing from the beta branch checkin, or something else?
Flags: needinfo?(matt.woodrow)
Just another data point:  I'm running firefox 30b5 (on 32-bit Windows 8.1 update) and get the same result of blank printed pages regardless of pdf file.
(In reply to Jim Figlik from comment #62)
I have just upgraded to Firefox 29.0.1, clicking "upgrade" says that I have the latest.
I am using newly installed Adobe Acrobat Standard v8.0 upgraded to v8.1.6

The page(http://www.sudoku.org.uk/Puzzles/Sudoku.asp) requires (installed) Flash v13.
Clicking on the print button, I go through the normal process of selecting a printer, including specifying a directory & file name. Although the page displays as expected, a blank page is created in the target file, no errors are display, as displayed by the local Acrobat Reader, also v8.1.6.

Do the same thing in IE v11.0.9600.17107 and the page is printed out as expected.
(In reply to Jim Figlik from comment #63)
> All Adobe items in Firefox/Options are set to use "Adobe Acrobat v8.1" in
> place of "use Adobe Acrobat in Firefox".

The problem occurs when one "prints" to create a PDF file.
Opening a pre-existing PDF file displays & prints properly.
The problem seems to be related to Adobe Flash printing on Firefox, if I attempt to print the original, 1-page puzzle, to a pre-defined printer (Epson WF-3540), for instance, 4 pages come out, headers, footers, but without the primary (flash generated) piece. Using IE 11, the page prints as expected, as Firefox used displays it.
(In reply to Jim Figlik from comment #76)
> (In reply to Jim Figlik from comment #62)
> I have just upgraded to Firefox 29.0.1, clicking "upgrade" says that I have
> the latest.
> I am using newly installed Adobe Acrobat Standard v8.0 upgraded to v8.1.6
> 
> The page(http://www.sudoku.org.uk/Puzzles/Sudoku.asp) requires (installed)
> Flash v13.
> Clicking on the print button, I go through the normal process of selecting a
> printer, including specifying a directory & file name. Although the page
> displays as expected, a blank page is created in the target file, no errors
> are display, as displayed by the local Acrobat Reader, also v8.1.6.
> 
> Do the same thing in IE v11.0.9600.17107 and the page is printed out as
> expected.
> (In reply to Jim Figlik from comment #63)
> > All Adobe items in Firefox/Options are set to use "Adobe Acrobat v8.1" in
> > place of "use Adobe Acrobat in Firefox".
> 
> The problem occurs when one "prints" to create a PDF file.
> Opening a pre-existing PDF file displays & prints properly.
> The problem seems to be related to Adobe Flash printing on Firefox, if I
> attempt to print the original, 1-page puzzle, to a pre-defined printer
> (Epson WF-3540), for instance, 4 pages come out, headers, footers, but
> without the primary (flash generated) piece. Using IE 11, the page prints as
> expected, as Firefox used displays it.

Downloaded 30.0b5 and it has more problems than 29.0.
29.0 prints an existing PDF file, 30.0b5 does not.

30.0b5 does not print a pdf from the web page (using the print key/function), blank page is produced.
Ok, confirmed that it's still broken on beta.

It appears that for windows printing we create a gfxWindowsSurface that is backed by a cairo recording surface. So when we call CreateSimilarSurface, we end up with a gfxUnknownSurface (since we don't have a c++ class for recording surfaces).

GetSize() isn't implemented for gfxUnknownSurface and we hit the same bug as before.

This patch seems like the most unobtrusive way to fix this, especially since we're pushing towards using Moz2D directly everywhere.

I guess the *right* fix would be to add gfxRecordingSurface, and to expose new cairo API to obtain the size from a cairo_recording_surface_t. I don't think that's worth doing for code we want to get rid of.
Attachment #8426804 - Flags: review?(bas)
Flags: needinfo?(matt.woodrow)
Blocks: 1008779
Duplicate of this bug: 1015192
Attachment #8426804 - Flags: review?(bas) → review+
This is still problem when printing from a web page using Adobe Flash to present content.

Using v30.0b7.exe I did not see any change from previous versions, for my problem. There is no problem when using other browsers (e.g. IE v11).

I attempted to print a web page (http://www.sudoku.org.uk/Puzzles/Sudoku.asp) utilizing Adobe Flash (v13) using the page's print routine (or Ctrl-P) to the Adobe v8.3.1 printer (creates PDF files). Only a blank page shows up.

However, a straight-up print, e.g. a Wall Street Journal page (http://online.wsj.com/articles/is-now-the-time-to-buy-a-4k-tv-set-1399645629) does print as one would expect.

The difference is the Adobe Flash module.
Please see below the results on Firefox 30 beta 9 (20140529161749):
- No printing issues using Win XP 32-bit, Win 7 64-bit, Win 8.1 64-bit
- PDF still prints white pages using Mac OSX 10.8.5 and Ubuntu 12.10 32-bit

Ubuntu was mentioned on comment 17, on Mac the issue seems to be more recent.

Reopened based on this.
Status: VERIFIED → REOPENED
OS: Windows 7 → All
Resolution: FIXED → ---
Matt - I'm setting the FF30 back to 'affected'.  Do you have time to look into this today/early Monday morning to see if there's a fix for those platforms? Having Windows work does help the majority of users, but we'll certainly hear it if Mac/Linux users can't print pdfs so anything that can be done to fix this before our final RC will be considered.
Flags: needinfo?(matt.woodrow)
Using W7 x64 standard PDF prints, but (there's always a but)
W7x64 using Flash v13 (e.g. http://www.sudoku.org.uk/Puzzles/Sudoku.asp) continues to print a blank page.

IE v11 continues to print out the Flash v13 output as expected.
Comment 87 was using Firefox v30b9.

Thx!
(In reply to Jim Figlik from comment #87)
> Using W7 x64 standard PDF prints, but (there's always a but)
> W7x64 using Flash v13 (e.g. http://www.sudoku.org.uk/Puzzles/Sudoku.asp)
> continues to print a blank page.
> 
> IE v11 continues to print out the Flash v13 output as expected.

Jim, flash printing is another issue, see bug 594525.
Was comment (In reply to Robert Kaiser (:kairo@mozilla.com) from comment #51)
> (In reply to l.borowka from comment #49)
> > Today I noticed that the version 29.0.1 prints, but also releases the second
> > page blank. I do not know why this is happening. In the preview I have one
> > page, and come to me two cards (one correct, one blank).
> 
> Please raise that as a separate bug, it might be a completely separate issue
> and for sure is a different symptom in both severity and what it actually
> does than the one we solved here.

Was this ever documented? I cannot reproduce this, but a customer of mine can.
Flags: needinfo?(borut)
Oh man, this bug just doesn't end. Unfortunately yesterday was a public holiday, so only just got to this now.

I've confirmed that this patch fixes printing for OSX. Building on linux now.
Attachment #8433030 - Flags: review?(roc)
Flags: needinfo?(matt.woodrow)
And confirmed that it also fixes the issue for ubuntu.

https://hg.mozilla.org/integration/mozilla-inbound/rev/817ede736aa

Lukas, this is a very low risk continuation of the previous fix, we should uplift it to beta if it's not too late.
Flags: needinfo?(lsblakk)
https://hg.mozilla.org/mozilla-central/rev/817ede736aab
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
From how I read the recent comment, Linux is probably not fixed yet, so let's keep this open (if I'm wrong, please resolve again).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #94)
> From how I read the recent comment, Linux is probably not fixed yet, so
> let's keep this open (if I'm wrong, please resolve again).

Comment 92 covers linux - also I'll be approving this for mozilla-release uplift as we have merged already.
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Flags: needinfo?(lsblakk)
Resolution: --- → FIXED
Comment on attachment 8417932 [details] [diff] [review]
Pass surface sizes in

Please land this to mozilla-release as well for our RC build today.
Attachment #8417932 - Flags: approval-mozilla-release+
(In reply to Lukas Blakk [:lsblakk] from comment #95)
> Comment 92 covers linux 

Oops, I completely missed that, thanks for catching! :)
https://hg.mozilla.org/releases/mozilla-release/rev/6da3dd0a2e7b
https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/6da3dd0a2e7b

@Liz - FWIW, I was holding off on setting firefox30 to fixed until this merged to release, since that's where any new Fx30 builds are going to ship from at this point.
Verified as fixed on Firefox 30 RC 20140603140158 under Ubuntu 12.10 32-bit and Mac OSX 10.8.5.
Verified as fixed on Windows 7 64bit, Ubuntu 14.04 32bit and Mac OS X 10.9.4 using Firefox 31 beta 8.
Status: RESOLVED → VERIFIED
Keywords: verifyme
Whiteboard: [pdfjs-d-printing] [qa+] → [pdfjs-d-printing] [qa!]
Hi!

I still have the problem in mozilla v29 until v33. But my problem is that I only have the issue with a certain pdf files. This files are generated pdf files from a RICOH printer. Somebody with the same problem? 
The problem started with mozilla 29.

Thanks!
Hi Vruiz, and thanks for your report. Given that your issue related to a specific pdf file, please file a new bug and if possible attach the PDF to the bug. Devs can then have a  look at. This particular bug has been fixed a while ago. Thanks.
(In reply to Henrik Skupin (:whimboo) from comment #103)
> Hi Vruiz, and thanks for your report. Given that your issue related to a
> specific pdf file, please file a new bug and if possible attach the PDF to
> the bug. Devs can then have a  look at. This particular bug has been fixed a
> while ago. Thanks.

Thanks! I have created a neg bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=1084327

I hope the description could help to solve the problem.

Thanks!
Blank pages for me too, but everything I've tried: pdfs from gmail and return tickets from amazon (non pdf). I also get a blank pdf when I use adobe plugin to print to pdf.
IE works.

I'm on Win10 Tech Preview
You need to log in before you can comment on or make changes to this bug.