1003707 - pdf.js print prints a white page

Status: VERIFIED FIXED

(Core :: Graphics: Layers, defect)

Description

[l.borowka]

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.

Comment 1

[l.borowka]

Please fix or remove built in pdf brovser. Please release fixed firefox version 29.0.1.

Comment 2

[Masatoshi Kimura [:emk]]

Is this a regression since Firefox 29? In other words? Was Firefox 28 unaffected?

Comment 3

[l.borowka]

(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.

Comment 4

[Masatoshi Kimura [:emk]]

Confirmed. A virtual printer drier was enough to reproduce the issue.

Comment 5

[Yury Delendik (:yury)]

So we are talking about 64bit version of Firefox for Windows. Can you replicate that on 32bit version?

Comment 6

[Masatoshi Kimura [:emk]]

Do I have to install 32-bit Windows only to confirm?

Comment 7

[Masatoshi Kimura [:emk]]

(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.

Comment 8

[l.borowka]

Please rapid improvement in error. I can easily view and print PDF documents.

Comment 9

[l.borowka]

Please rapid improvement in error. You can not easily view and print PDF documents.

Comment 10

[Yury Delendik (:yury)]

Looks like it was introduced in 29.0b9 (http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/)

http://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=3a4f085a6398&tochange=da279b9f523a

Comment 11

[Alice0775 White]

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

Comment 12

[Yury Delendik (:yury)]

I can confirm it's a regression due to bug 991767 patch:

The first bad revision is:
changeset:   184764:55422890fb8f
user:        Matt Woodrow <[e-mail]>
date:        Mon Apr 07 16:07:12 2014 +1200
summary:     Bug 991767 - Use Moz2D for printing surfaces. r=roc, a=sledru

Comment 15

[Lukas Blakk [:lsblakk] use ?needinfo]

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?

Comment 16

[Matt Woodrow (:mattwoodrow)]

(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.

Comment 17

[Benjamin Kaduk]

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.

Comment 18

[Robert Kaiser]

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...

Comment 19

[Robert Kaiser]

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. :(

Comment 21

[Matt Woodrow (:mattwoodrow)]

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.

Comment 22

[Matt Woodrow (:mattwoodrow)]

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.

Comment 23

[Matt Woodrow (:mattwoodrow)]

Attachment: One idea

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.

Comment 26

[Nigel]

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

Comment 27

[Ryan VanderMeulen [:RyanVM]]

Bug 991767 backed out from mozilla-release.

https://hg.mozilla.org/releases/mozilla-release/rev/07e9f010bf08

Comment 28

[Matt Woodrow (:mattwoodrow)]

Attachment: Pass surface sizes in

Comment 31

[Catalin Varga [QA][:VarCat]]

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

Comment 32

[keithbriand]

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.

Comment 33

[l.borowka]

Firefox 30 beta 2 have this same problem. :/

Comment 34

[:Gijs (he/him)]

(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.

Comment 35

[Matt Woodrow (:mattwoodrow)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/3b5fb4abaa3f

Comment 36

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/3b5fb4abaa3f

Comment 38

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Can this be tested by an automated test?

Comment 39

[Matt Woodrow (:mattwoodrow)]

(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.

Comment 40

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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.

Comment 41

[Mihaela Velimiroviciu (:mihaelav)]

Created Moztrap test: https://moztrap.mozilla.org/manage/case/12971/

Comment 42

[pieter kristensen]

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.

Comment 43

[l.borowka]

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.

Comment 44

[Mike Hommey [:glandium]]

(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?

Comment 45

[Vladimir G. Ivanovic]

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.

Comment 46

[Matt Woodrow (:mattwoodrow)]

(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 47

[Matt Woodrow (:mattwoodrow)]

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.

Comment 48

[Sylvestre Ledru [:Sylvestre]]

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.

Comment 49

[l.borowka]

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).

Comment 50

[pieter kristensen]

Here too we get one blank page. Strange.

Comment 51

[Robert Kaiser]

(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.

Comment 52

[l.borowka]

(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

Comment 53

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/835c58e7e65c
https://hg.mozilla.org/releases/mozilla-beta/rev/7d945895a6d9

Comment 54

[Ryan VanderMeulen [:RyanVM]]

This needs rebasing for beta.

Comment 55

[Liz Henry (:lizzard) (relman/hg->git project)]

Kairo, should this stay resolved, and we file a new bug with the new crash stack (though the same signature)?

Comment 56

[Liz Henry (:lizzard) (relman/hg->git project)]

whoops, right comment, wrong tab/bug.

Comment 57

[Matt Woodrow (:mattwoodrow)]

Attachment: Beta branch patch

Comment 58

[Paul Silaghi, QA [:pauly]]

Verified fixed 32.0a1 (2014-05-12), Win 7 x64

Comment 59

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/956578072396

Comment 60

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/956578072396

Comment 61

[psudrumjas]

Should this problem have been fixed on Firefox 30b4?  For me, I still get white pages when printing.

Comment 62

[Jim Figlik]

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.

Comment 63

[Jim Figlik]

All Adobe items in Firefox/Options are set to use "Adobe Acrobat v8.1" in place of "use Adobe Acrobat in Firefox".

Comment 64

[Catalin Varga [QA][:VarCat]]

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.

Comment 65

[Steve Singer (:stevensn)]

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.

Comment 66

[LL25255252]

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

Comment 67

[Cork]

(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.

Comment 68

[LL25255252]

I've opened Bug 1012444 ( Firefox 29.0.1 built-in PDF viewer doesn't print correctly some PDF files).
Thank you @Cork.

Comment 69

[Lukas Blakk [:lsblakk] use ?needinfo]

Matt - what's missing for this on Beta?  Have you got a follow up fix coming here for branches?

Comment 70

[Matt Woodrow (:mattwoodrow)]

(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 71

[Lukas Blakk [:lsblakk] use ?needinfo]

(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

Comment 72

[Lukas Blakk [:lsblakk] use ?needinfo]

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.

Comment 73

[Paul Silaghi, QA [:pauly]]

(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

Comment 74

[Lukas Blakk [:lsblakk] use ?needinfo]

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?

Comment 75

[psudrumjas]

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.

Comment 76

[Jim Figlik]

(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.

Comment 77

[Jim Figlik]

(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.

Comment 78

[Matt Woodrow (:mattwoodrow)]

Attachment: Implement size for recording surface created for windows printing

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.

Comment 80

[Jim Figlik]

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.

Comment 81

[Matt Woodrow (:mattwoodrow)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/809f9bcbd7f2

Comment 82

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/809f9bcbd7f2

Comment 83

[Ryan VanderMeulen [:RyanVM]]

Going off the assumption that the prior approvals on this bug still apply to the follow-up patch :)

https://hg.mozilla.org/releases/mozilla-aurora/rev/ad2258fa2e1a
https://hg.mozilla.org/releases/mozilla-beta/rev/2a6b6da3de15

Comment 84

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/2a6b6da3de15

Comment 85

[Petruta Horea [:phorea], Desktop Test Engineering (back on Sep 5th)]

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.

Comment 86

[Lukas Blakk [:lsblakk] use ?needinfo]

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.

Comment 87

[Jim Figlik]

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 88

[Jim Figlik]

Comment 87 was using Firefox v30b9.

Thx!

Comment 89

[Petruta Horea [:phorea], Desktop Test Engineering (back on Sep 5th)]

(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.

Comment 90

[jonwilks]

Was comment (In reply to Robert Kaiser (:[e-mail]) 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.

Comment 91

[Matt Woodrow (:mattwoodrow)]

Attachment: Fix size for gfxQuartzSurface

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.

Comment 92

[Matt Woodrow (:mattwoodrow)]

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.

Comment 93

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/817ede736aab

Comment 94

[Robert Kaiser]

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 95

[Lukas Blakk [:lsblakk] use ?needinfo]

(In reply to Robert Kaiser (:[e-mail]) 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.

Comment 96

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 8417932 [details] [diff] [review]
Pass surface sizes in

Please land this to mozilla-release as well for our RC build today.

Comment 97

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/1cf1228b8433
https://hg.mozilla.org/releases/mozilla-beta/rev/6da3dd0a2e7b

Comment 98

[Robert Kaiser]

(In reply to Lukas Blakk [:lsblakk] from comment #95)
> Comment 92 covers linux 

Oops, I completely missed that, thanks for catching! :)

Comment 99

[Ryan VanderMeulen [:RyanVM]]

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.

Comment 100

[Petruta Horea [:phorea], Desktop Test Engineering (back on Sep 5th)]

Verified as fixed on Firefox 30 RC 20140603140158 under Ubuntu 12.10 32-bit and Mac OSX 10.8.5.

Comment 101

[Bogdan Maris, Desktop Test Engineering]

Verified as fixed on Windows 7 64bit, Ubuntu 14.04 32bit and Mac OS X 10.9.4 using Firefox 31 beta 8.

Comment 102

[vruiz]

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!

Comment 103

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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.

Comment 104

[vruiz]

(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!

Comment 105

[stievu]

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