PDF.js prints blank pages

[Benjamin Kaduk]

The recent upgrade to 29.0+build1-0ubuntu0.12.04.2 (on Ubuntu 12.04.4 LTS) cause printing from PDF.js to emit essentially blank output (the spooled files are very small, and contain showpage directives with no page content, i.e., blank pages come out of the printer). Users can download the file from the down-arrow menu and print using a standalone viewer with no issue.

This is probably https://bugzilla.mozilla.org/show_bug.cgi?id=1003707

[Borut-q (borut-q)]

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.

[Borut-q (borut-q)]

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

[Vyv03354 (vyv03354)]

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

[Borut-q (borut-q)]

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

[Vyv03354 (vyv03354)]

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

[Ydelendik (ydelendik)]

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

[Vyv03354 (vyv03354)]

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

[Vyv03354 (vyv03354)]

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

[Borut-q (borut-q)]

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

[Borut-q (borut-q)]

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

[Ydelendik (ydelendik)]

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

[Alice0775 (alice0775)]

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

[Ydelendik (ydelendik)]

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

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

[Ydelendik (ydelendik)]

*** Bug 999284 has been marked as a duplicate of this bug. ***

[Tdowner (tdowner)]

*** Bug 1004150 has been marked as a duplicate of this bug. ***

[Lsblakk (lsblakk)]

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?

[Matt-woodrow (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.

[Kaduk-ffbz (kaduk-ffbz)]

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.

[Kairo-kairo (kairo-kairo)]

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

[Kairo-kairo (kairo-kairo)]

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

[Vyv03354 (vyv03354)]

*** Bug 1004385 has been marked as a duplicate of this bug. ***

[Matt-woodrow (matt-woodrow)]

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.

[Matt-woodrow (matt-woodrow)]

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.

[Matt-woodrow (matt-woodrow)]

Created attachment 8416341
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.

[Gijskruitbosch+bugs (gijskruitbosch+bugs)]

*** Bug 1005188 has been marked as a duplicate of this bug. ***

[Gijskruitbosch+bugs (gijskruitbosch+bugs)]

*** Bug 1005192 has been marked as a duplicate of this bug. ***

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Firefox-e (firefox-e)]

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

[Ryanvm (ryanvm)]

Bug 991767 backed out from mozilla-release.

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

[Matt-woodrow (matt-woodrow)]

Created attachment 8417932
Pass surface sizes in

[Gijskruitbosch+bugs (gijskruitbosch+bugs)]

*** Bug 1006649 has been marked as a duplicate of this bug. ***

[Tdowner (tdowner)]

*** Bug 1006672 has been marked as a duplicate of this bug. ***

[Catalin-varga (catalin-varga)]

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

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

[Borut-q (borut-q)]

Firefox 30 beta 2 have this same problem. :/

[Gijskruitbosch+bugs (gijskruitbosch+bugs)]

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

[Matt-woodrow (matt-woodrow)]

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

[Cbook (cbook)]

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

[Gijskruitbosch+bugs (gijskruitbosch+bugs)]

*** Bug 1007672 has been marked as a duplicate of this bug. ***

[Hskupin (hskupin)]

Can this be tested by an automated test?

[Matt-woodrow (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.

[Lsblakk (lsblakk)]

(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

[Lsblakk (lsblakk)]

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.

[Paul-silaghi (paul-silaghi)]

(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

[Lsblakk (lsblakk)]

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?

[John Schuetz (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.

[Jim001 (jim001)]

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

[Jim001 (jim001)]

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

[Matt-woodrow (matt-woodrow)]

Created attachment 8426804
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.

[Benjamin Kaduk (kaduk-launchpad)]

The firefox 29.0.1+build2-0ubuntu0.12.04.1 in the ubuntu-mozilla-security ppa does not exhibit this bug for me.

[Xavierupo1996 (xavierupo1996)]

*** Bug 1015192 has been marked as a duplicate of this bug. ***

[Jim001 (jim001)]

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.

[Matt-woodrow (matt-woodrow)]

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

[Cbook (cbook)]

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

[Ryanvm (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

[Ryanvm (ryanvm)]

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

[Petruta-rasa (petruta-rasa)]

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.

[Lsblakk (lsblakk)]

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.

[Jim001 (jim001)]

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.

[Jim001 (jim001)]

Comment 87 was using Firefox v30b9.

Thx!

[Petruta-rasa (petruta-rasa)]

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

[Jonathan-wilkins (jonathan-wilkins)]

Was comment (In reply to Robert Kaiser (:<email address hidden>) 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.

[Matt-woodrow (matt-woodrow)]

Created attachment 8433030
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.

[Matt-woodrow (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.

[Cbook (cbook)]

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

[Kairo-kairo (kairo-kairo)]

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

[Lsblakk (lsblakk)]

(In reply to Robert Kaiser (:<email address hidden>) 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.

[Lsblakk (lsblakk)]

Comment on attachment 8417932
Pass surface sizes in

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

[Ryanvm (ryanvm)]

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

[Kairo-kairo (kairo-kairo)]

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

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

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

[Petruta-rasa (petruta-rasa)]

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

[Launchpad Janitor (janitor)]

This bug was fixed in the package firefox - 30.0+build1-0ubuntu0.13.10.3

---------------
firefox (30.0+build1-0ubuntu0.13.10.3) saucy-security; urgency=medium

  * New upstream stable release (FIREFOX_30_0_BUILD1)
    - see LP: #1326690 for USN information

  * Refresh patches
    - update d/p/test-integration/xpcshell-disable-tests-which-need-appdir-write-access.patch
    - update debian/patches/unity-menubar.patch
  * Drop patches, fixed upstream
    - remove debian/patches/aarch64-support.patch
    - remove debian/patches/fix-armhf-build.patch
  * Build with --enable-gstreamer=1.0 on 14.04 and later
  * Correctly override the duckduckgo plugin for the gd locale
  * Add patch to fix a build issue on architectures where WebRTC isn't enabled
 -- Chris Coulson <email address hidden> Thu, 05 Jun 2014 09:26:31 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package firefox - 30.0+build1-0ubuntu0.12.04.3

---------------
firefox (30.0+build1-0ubuntu0.12.04.3) precise-security; urgency=medium

  * New upstream stable release (FIREFOX_30_0_BUILD1)
    - see LP: #1326690 for USN information

  * Refresh patches
    - update d/p/test-integration/xpcshell-disable-tests-which-need-appdir-write-access.patch
    - update debian/patches/unity-menubar.patch
  * Drop patches, fixed upstream
    - remove debian/patches/aarch64-support.patch
    - remove debian/patches/fix-armhf-build.patch
  * Build with --enable-gstreamer=1.0 on 14.04 and later
  * Correctly override the duckduckgo plugin for the gd locale
  * Add patch to fix a build issue on architectures where WebRTC isn't enabled
 -- Chris Coulson <email address hidden> Thu, 05 Jun 2014 09:27:41 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package firefox - 30.0+build1-0ubuntu0.14.04.3

---------------
firefox (30.0+build1-0ubuntu0.14.04.3) trusty-security; urgency=medium

  * New upstream stable release (FIREFOX_30_0_BUILD1)
    - see LP: #1326690 for USN information

  * Refresh patches
    - update d/p/test-integration/xpcshell-disable-tests-which-need-appdir-write-access.patch
    - update debian/patches/unity-menubar.patch
  * Drop patches, fixed upstream
    - remove debian/patches/aarch64-support.patch
    - remove debian/patches/fix-armhf-build.patch
  * Build with --enable-gstreamer=1.0 on 14.04 and later
  * Correctly override the duckduckgo plugin for the gd locale
  * Add patch to fix a build issue on architectures where WebRTC isn't enabled
 -- Chris Coulson <email address hidden> Thu, 05 Jun 2014 08:33:35 +0100

[Bogdan-maris (bogdan-maris)]

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

[Vruiz-0 (vruiz-0)]

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!

[Hskupin (hskupin)]

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.

[Vruiz-0 (vruiz-0)]

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

[Huy (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