1184604 - Print To File In PDF Format Not Working

Status: RESOLVED FIXED

(Core :: Printing: Output, defect)

Description

[drichard]

Attachment: Yahoo.com export to PDF using Firefox 38 -- works.

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:39.0) Gecko/20100101 Firefox/39.0
Build ID: 20150630154324

Steps to reproduce:

When viewing a web page if you do a File > Print and then select "Print To File" you can select PDF format.  You then enter the file name and desired folder and make sure the PDF radio button is selected.  It then goes through the process of printing and you are supposed to immediately have a PDF file on the file system.


Actual results:

On Firefox 38, this works correctly.

On Firefox 39, the file is created with a .pdf extension but the contents of the file is actually a postscript file.   


Expected results:

The resulting file should be in PDF format if the PDF radio button is picked and PS format if that button is toggled.   It seems to be generating PS regardless of which radio button is selected.

Comment 1

[drichard]

Attachment: Yahoo.com export to PDF using Firefox 39 -- writes out a PS file

Comment 2

[Loic]

Did you test with a fresh profile?
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

Comment 3

[drichard]

Thank you for the response and idea, I put a user account back to defaults and created a totally new profile with the same results.  The PDF that was exported is in postscript format.

file /home/largo/tmp/yahoo_fresh_39.pdf
/home/largo/tmp/yahoo_fresh_39.pdf: PostScript document text conforming DSC level 3.0, Level 2

Comment 4

[Gingerbread Man]

(In reply to drichard from comment #0)
> On Firefox 38, this works correctly.
> 
> On Firefox 39, the file is created with a .pdf extension but the contents of
> the file is actually a postscript file.   

Could you find the regression range?
mozregression --good-release 38 --bad-release 39
http://mozilla.github.io/mozregression/

Comment 5

[drichard]

Here is what I have been able to find.

On Ubuntu 14.04, it works as expected.  So I was unable to run mozgression on this computer, because there is no failure to detect.

In our use case, we are using OpenSuse 11.4, and this is where it's happening.  mozgression cannot be installed on OpenSuse 11.4, there are some python problems that cannot be overcome.

So I installed the last 38, 38.0.6 and it worked as expected.

I then installed 39.b1 (beta 1) and it does not work.

So I feel we have narrowed this down to OpenSuse 11.X, between 38.0.6 and 39.b1

Comment 6

[Loic]

If Mozreg doesn't work on your OS, you can still do that manually by dichotomy by downloading Nightly builds from the Moz's FTP:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2015/

The daily build are in the folder "mozilla-central", just download each nightly as zip for a standalone use (maybe with a custom profile with -p "test_profile" -no-remote)

FF39 builds started at the end of 02/2015: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2015/02/

Comment 7

[drichard]

I am making some progress with the nightly builds.  Firefox 39 builds started on 2/23 and when you do a file > print it tells you that printing it not implemented because of issue #927188.   In the nightly from 3/16, printing works again and the failure occurs -- FF is writing out a PS file instead of a PDF.

I tested the 2/21 build, the last of Firefox 38 and it too had the printing dialog unhooked and not available for testing.

I'm open to recommendations, I feel that #927188 might be the issue.   Should I roll back further into the nightly builds prior to 2/21 and find the point that the printer dialog was unhooked?

Comment 8

[Gingerbread Man]

(In reply to drichard from comment #7)
> Firefox 39 builds started on 2/23 and when you do a file > print
> it tells you that printing it not implemented because of issue #927188.

Try disabling e10s (multiprocess) under about:preferences#general then restarting Firefox.

> I'm open to recommendations, I feel that #927188 might be the issue.

E10s isn't enabled in the Release channel and bug 927188 isn't resolved,
so I don't see how it could be the cause of your issue.

Comment 9

[drichard]

Thank you for continued feedback, e10s was already disabled.  

I was willing to do the leg work to find the exact regression day of the builds, but file > print does not work in a large number of -central builds, and when it started working it was broken.   Is there another line of builds that can be tested to find this issue?  

I have 800 people that cannot export to PDF right now.

Comment 10

[Loic]

You need to create a custom profile to use with mozregression:
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

[1] In this profile, type about:config and set all variables "browser.tabs.remote.autostart" to FALSE, even this one with a number at the end.

Then run the dichotomy with this profile for each nightly. If the profile is started in e10s mode (it could happen sometimes), redo step [1], restart the nighty and make your print test.

with these instructions, you should be able to test the nightlies without e10s and avoid all print issues related to e10s to find the underlying print bug.

Comment 11

[Loic]

NB:
When you got the last good build and the first bad build, type about:buildconfig and copy for both ones the link under "Source" (ex: https://hg.mozilla.org/releases/mozilla-release/rev/d3b3e57e8088)

Comment 12

[drichard]

Thank you everyone for some knowledge transfer in this matter and clarification.  I was able to get the daily builds running on OpenSuse 11.4 and reliably found and replicate the failure.

Last good build is:
2015-03-09
https://hg.mozilla.org/mozilla-central/rev/eab4a81e4457
(( File > Print > Print To File creates a PDF ))

First bad build is:
2015-03-10
https://hg.mozilla.org/mozilla-central/rev/6686aacf006f
(( File > Print > Print To File creates a PS ))

file yahoo*ex*.pdf
yahoo0309export.pdf: PDF document, version 1.5
yahoo0310export.pdf: PostScript document text conforming DSC level 3.0, Level 2

Comment 13

[drichard]

I just checked FF 40 beta 6 and it's exporting postscript files too.

Comment 14

[Gingerbread Man]

Thank you for the update. Push log:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=eab4a81e4457&tochange=6686aacf006f

Bug 1090448 looks like the likely suspect.
Bug 1082579 is another printing-related bug in the respective time range.

(In reply to drichard from comment #13)
> I just checked FF 40 beta 6 and it's exporting postscript files too.

Could you also check the latest Nightly in a brand new profile?
https://nightly.mozilla.org
https://support.mozilla.org/kb/profile-manager-create-and-remove-firefox-profiles

Comment 15

[drichard]

I brought down the nightly build, identified as Firefox 42a1 with a build date of 7-22.  I wiped all user settings and then turned off e10s so that I could print to pdf.  I then exported the current web page (yahoo.com) into PDF format and it generated a PS file instead -- just as we have seen in FF 39.

file yahoo_ff42.pdf
yahoo_ff42.pdf: PostScript document text conforming DSC level 3.0, Level 2

Being that I tested the beta build of FF 40 yesterday, I feel that FF 40 and FF 42 are affected.

OpenSuse 11.4 is very similar to Suse SLES/SLED 11 which is heavily used by enterprise users.

Comment 16

[Lawrence Mandel [:lmandel] (use needinfo)]

Tracking 40+ as we're not going to ship a point release for this issue in 39.

jst - Who knows pdf printing and you think can help investigate this regression?

Comment 17

[Mike Conley (:mconley) (:⚙️)]

I can look into this.

Comment 18

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

For what it's worth, I've been getting PDF files just fine, and if I explicitly choose Postscript (PDF is the default), I get Postscript.  I'm running self-built 64-bit Linux debug builds on Ubuntu 15.04.

Comment 19

[Mike Conley (:mconley) (:⚙️)]

I am having no luck reproducing this. Like dbaron, I appear to be getting PDF files just fine with the STR in comment 0, from 40beta through DevEdition and Nightly.

karlt, any idea what might be happening here?

Comment 20

[drichard]

I did some testing on various flavors of Linux with the nightly build from last night.  This does appear to be specific (so far) to OpenSuse 11.4.   Let me know if there is some "ldd" type things that I can do to help find specific libraries that are affecting this.

OpenSuse 11.2 (Crashes)
------------------------------
./firefox
XPCOMGlueLoad error for file /u/ff/firefox/libmozgtk.so:
libgtk-3.so.0: cannot open shared object file: No such file or directory
Couldn't load XPCOM.

OpenSuse 11.4 (Runs, but creates PS files instead of PDF files when printing to PDF)
------------------------------------------------------------------------------------

OpenSuse 13.2 (Runs and works as expected)
------------------------------------------

Ubuntu 14.04 (Runs and works as expected)
-----------------------------------------

Centos 6.4 (Crashes)
--------------------
./firefox
XPCOMGlueLoad error for file /u/ff/firefox/libmozgtk.so:
libgtk-3.so.0: cannot open shared object file: No such file or directory
Couldn't load XPCOM.

Comment 21

[Karl Tomlinson (:karlt)]

OpenSuSE 11.4 shipped with GTK+ 2.22.1.

Is that the version on the machines failing here?
ls -l /usr/lib64/libgtk-x11-2.0.so to identify.

The old code to choose PS on versions prior to 2.24 only ran when
gtk_print_settings_get(GTK_PRINT_SETTINGS_OUTPUT_FILE_FORMAT) returned null.

http://hg.mozilla.org/mozilla-central/rev/fb3cbae160df#l1.54

The new code is always force PS for versions prior to 2.24.

http://hg.mozilla.org/mozilla-central/rev/fb3cbae160df#l3.19

I guess this would work better if the gtk_print_settings_get() and pre-2.24
logic were in a GetOutputFormat override and the version logic is used only
when there is nothing in the print settings.

But I don't understand why the bug doesn't exist in reverse when trying to
print PS from version 2.24.

It may be possible to reproduce by tweaking the 2.24 check to return false,
but I'm not sure.

Is GTK+ 3 installed on 11.4?
Comment 20 implies so, but that surprises me.

Comment 22

[drichard]

As requested:

linux-xmvz:/u2/local/lib # ls -l /usr/lib64/libgtk-x11-2.0.so
lrwxrwxrwx 1 root root 26 Feb  8  2013 /usr/lib64/libgtk-x11-2.0.so -> libgtk-x11-2.0.so.0.2200.1

It looks like GTK 3 is not installed at all on OpenSuse 11.4, even in preview form.

I installed FF on another OpenSuse 11.4 server and it failed in the same way. 

I then tried to print to PS to see if it in fact created a PDF...and it did not.  Print to PDF and Print to PS creates identical files of the same file size.

rpm -qa | grep libgtk | sort
libgtk-2_0-0-2.22.1-13.13.2.x86_64
libgtk-2_0-0-32bit-2.22.1-13.13.2.x86_64
libgtkglext-x11-1_0-0-1.2.0-186.1.x86_64
libgtkhtml-3_14-19-3.32.1-4.1.x86_64
libgtkimageview0-1.6.4-6.1.x86_64
libgtkmm-2_4-1-2.22.0-2.1.x86_64
libgtksourceview-2_0-0-2.10.5-4.1.x86_64
libgtk-vnc-1_0-0-0.4.2-4.1.x86_64

Comment 23

[Mike Conley (:mconley) (:⚙️)]

Does comment 22 make it clearer what might be going on?

Comment 24

[Karl Tomlinson (:karlt)]

(In reply to drichard from comment #22)
> lrwxrwxrwx 1 root root 26 Feb  8  2013 /usr/lib64/libgtk-x11-2.0.so ->
> libgtk-x11-2.0.so.0.2200.1

Thanks.  That's GTK+ 22.1 as originally shipped with 11.4, which is consistent with the suspicion in comment 21 re the changes in the version checking code.

Comment 25

[drichard]

Can we get this code reverted back to the old version checking technique?  Suse 11.X (OpenSuse 11.x) is still a sold and supported product for Enterprise users.  It's similar to Firefox ESR in that it has a longer duty cycle and is patched.  We (and may other people) will move off this in 2016, but it's still in production for a good number of months while software is prepped for upgrade and QA.

Comment 26

[Mike Conley (:mconley) (:⚙️)]

Alright, I'll see if I can work out a patch here for this tomorrow. I'm hoping somebody in here who is experiencing this bug can help me test my builds to make sure I've actually fixed it.

Comment 27

[drichard]

I can absolutely test nightly builds if this code is merged and report back the results

Comment 28

[Mike Conley (:mconley) (:⚙️)]

Attachment: MozReview Request: Bug 1184604 - Lazily override printer output format on Linux if not already set. r?karlt

Bug 1184604 - Lazily override printer output format on Linux if not already set. r?karlt

GTK versions 2.24 incorrectly advertise themselves as able to print PDFs, even
when they can't. We were wholesale setting the output format to PostScript for
these older GTK versions, without giving the user the opportunity to override
it. We now lazily determine whether or not the output should be in PostScript,
which should give the user the opportunity to override.

Comment 29

[Mike Conley (:mconley) (:⚙️)]

Try build incoming here: https://treeherder.mozilla.org/#/jobs?repo=try&revision=5cd2e0bc0ec5

I'll needinfo you, drichard, when it's ready to test.

Comment 30

[Mike Conley (:mconley) (:⚙️)]

x86 build: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-5cd2e0bc0ec5/try-linux/firefox-42.0a1.en-US.linux-i686.tar.bz2

x64 build: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-5cd2e0bc0ec5/try-linux64/firefox-42.0a1.en-US.linux-x86_64.tar.bz2

Comment 31

[drichard]

Thank you for the patch attempt, very sadly on OpenSuse 11.4:

linux-xmvz:/u/firefox_42/firefox # ./firefox -no-remote
XPCOMGlueLoad error for file /u/firefox_42/firefox/libmozgtk.so:
libgtk-3.so.0: cannot open shared object file: No such file or directory
Couldn't load XPCOM.

Is there an environmental variable that can force FF to make no attempt to use GTK3?  Or is this a compile time option only?

Comment 32

[Sylvestre Ledru [:Sylvestre]]

I guess we won't have a fix for 40 today. Marking it as won't fix then.

Comment 33

[drichard]

The build I was testing was 42 alpha, how is this related to FF 40?  Is GTK3 going to be a requirement on a certain release that is upcoming?  I found the bugzilla issue and it doesn't look like it's finished yet and/or even working yet.

If FF is going to drop support for these enterprise version 11s, I would hope there would be lots of advance warning for those of us with substantial work to be done to migrate.  Remember, OpenSuse/Suse 11 is still actively being sold and patched as the latest release.

Comment 34

[Loic]

(In reply to drichard from comment #33)
> The build I was testing was 42 alpha, how is this related to FF 40?  Is GTK3
> going to be a requirement on a certain release that is upcoming?  I found
> the bugzilla issue and it doesn't look like it's finished yet and/or even
> working yet.

The bug is in Firefox since the version 39, so the versions 40+ are affected too. According to the delay remaining before the release of FF40, the bugfix will be not available for FF40 (but probably for FF41). GTK3 has been recently  introduced in FF42.

Comment 35

[drichard]

Thank you for the information.  

As it turns out a very early version of GTK3 was available as an optional install on Opensuse 11.4, which I just installed and the test build from @mconley worked!  I was able to export to PDF with this patch applied.   So if there is still time, this would be nice to have in FF 40.

Comment 36

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8641762 [details]
MozReview Request: Bug 1184604 - Lazily override printer output format on Linux if not already set. r?karlt

Bug 1184604 - Lazily override printer output format on Linux if not already set. r?karlt

GTK versions 2.24 incorrectly advertise themselves as able to print PDFs, even
when they can't. We were wholesale setting the output format to PostScript for
these older GTK versions, without giving the user the opportunity to override
it. We now lazily determine whether or not the output should be in PostScript,
which should give the user the opportunity to override.

Comment 37

[Karl Tomlinson (:karlt)]

Comment on attachment 8641762 [details]
MozReview Request: Bug 1184604 - Lazily override printer output format on Linux if not already set. r?karlt

https://reviewboard.mozilla.org/r/14601/#review13525

> GTK versions 2.24 incorrectly advertise themselves as able to print PDFs,
> even

Please change this to "versions *prior to* 2.24".

::: widget/gtk/nsPrintSettingsGTK.cpp:219
(Diff revision 1)
> +    if (!fmtGTK) {

Should check that mGTKPrinter is not null here.

Also interpreting fmtGTK here, when not null, would mean there is no need for the other gtk_print_settings_get() code in nsDeviceContextSpecGTK::GetSurfaceForPrinter().

http://hg.mozilla.org/mozilla-central/annotate/fb3cbae160df/widget/gtk/nsDeviceContextSpecG.cpp#l151

Comment 38

[drichard]

Would be very happy to test a reworked patch for this.  Our users are very anxious to be able to create PDFs again.

Comment 39

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8641762 [details]
MozReview Request: Bug 1184604 - Lazily override printer output format on Linux if not already set. r?karlt

Bug 1184604 - Lazily override printer output format on Linux if not already set. r?karlt

GTK versions prior to 2.24 incorrectly advertise themselves as able to print PDFs,
even when they can't. We were wholesale setting the output format to PostScript for
these older GTK versions, without giving the user the opportunity to override
it. We now lazily determine whether or not the output should be in PostScript,
which should give the user the opportunity to override.

Comment 40

[Karl Tomlinson (:karlt)]

Comment on attachment 8641762 [details]
MozReview Request: Bug 1184604 - Lazily override printer output format on Linux if not already set. r?karlt

https://reviewboard.mozilla.org/r/14601/#review14113

::: widget/gtk/nsPrintSettingsGTK.cpp:215
(Diff revision 2)
> +  if (format == nsIPrintSettings::kOutputFormatNative && mGTKPrinter) {
> +    const gchar* fmtGTK =
> +      gtk_print_settings_get(mPrintSettings,
> +                             GTK_PRINT_SETTINGS_OUTPUT_FILE_FORMAT);
> +    if (fmtGTK) {
> +      if (nsDependentCString(fmtGTK).EqualsIgnoreCase("pdf")) {
> +        format = nsIPrintSettings::kOutputFormatPDF;
> +      } else {
> +        format = nsIPrintSettings::kOutputFormatPS;
> +      }
> +    } else {

I think it still makes sense to use gtk_print_settings_get() even when there is no mGTKPrinter.

That would be more consistent with the code prior to
http://hg.mozilla.org/mozilla-central/rev/fb3cbae160df#l1.54

That involves removing " && mGTKPrinter" and inserting "if (mGtkPrinter) " after "if (fmtGTK) \{ \[...\] \} else ".

Comment 41

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8641762 [details]
MozReview Request: Bug 1184604 - Lazily override printer output format on Linux if not already set. r?karlt

Bug 1184604 - Lazily override printer output format on Linux if not already set. r?karlt

GTK versions prior to 2.24 incorrectly advertise themselves as able to print PDFs,
even when they can't. We were wholesale setting the output format to PostScript for
these older GTK versions, without giving the user the opportunity to override
it. We now lazily determine whether or not the output should be in PostScript,
which should give the user the opportunity to override.

Comment 42

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8641762 [details]
MozReview Request: Bug 1184604 - Lazily override printer output format on Linux if not already set. r?karlt

I assume you meant like this, with an else-if?

Comment 43

[Karl Tomlinson (:karlt)]

Comment on attachment 8641762 [details]
MozReview Request: Bug 1184604 - Lazily override printer output format on Linux if not already set. r?karlt

https://reviewboard.mozilla.org/r/14601/#review14739

(In reply to Mike Conley (:mconley) - (Going dark Aug 20 - Sept 11) from comment #42)
> I assume you meant like this, with an else-if?

Yes, thanks.

Comment 44

[Mike Conley (:mconley) (:⚙️)]

url:        https://hg.mozilla.org/integration/mozilla-inbound/rev/f294f9e327aced29545eec980445b6ae2ad4aca6
changeset:  f294f9e327aced29545eec980445b6ae2ad4aca6
user:       Mike Conley <[e-mail]>
date:       Fri Jul 31 13:53:49 2015 -0400
description:
Bug 1184604 - Lazily override printer output format on Linux if not already set. r=karlt

GTK versions prior to 2.24 incorrectly advertise themselves as able to print PDFs,
even when they can't. We were wholesale setting the output format to PostScript for
these older GTK versions, without giving the user the opportunity to override
it. We now lazily determine whether or not the output should be in PostScript,
which should give the user the opportunity to override.

Comment 45

[drichard]

Can this be back ported to FF 41 too?  I can test it then on a daily build and move it to our users once it's QA'd.   It would really help us greatly to have this patch in a version using GTK2, prior to your migration to GTK3.  GTK3 will require extensive testing and optimization work by me before we can move that live.

Comment 46

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8641762 [details]
MozReview Request: Bug 1184604 - Lazily override printer output format on Linux if not already set. r?karlt

Approval Request Comment
[Feature/regressing bug #]:

Bug 1090448

[User impact if declined]:

Linux users running with a distro using GTK+ 22.1 will be unable to print to PDF - only Postscript.

[Describe test coverage new/current, TreeHerder]:

Still waiting on Treeherder to give the all green, and will ask original reporter to test the build, as I don't have an appropriate version of Linux to test with (though the user had verified that our technique worked on an earlier patch).

[Risks and why]: 

Seems like small risk. It's Linux, and it's printing PDFs, which is a non-zero user group, but likely quite small. This code is self-contained enough to not affect any other function of Gecko.

[String/UUID change made/needed]:

None.

Comment 47

[Mike Conley (:mconley) (:⚙️)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=db2c7ff215ba

Comment 48

[Mike Conley (:mconley) (:⚙️)]

Try build for rebase on 41 coming in here for drichard to verify:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=cf6db1b7f8e0

Comment 49

[Mike Conley (:mconley) (:⚙️)]

Try builds of 41 for dirchard:

Linux x86: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-cf6db1b7f8e0/try-linux/firefox-41.0.en-US.linux-i686.tar.bz2

Linux x64: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-cf6db1b7f8e0/try-linux64/firefox-41.0.en-US.linux-x86_64.tar.bz2

Can you please verify that these builds work correctly for you?

Comment 50

[drichard]

I downloaded the 64bit version, and installed on our server and it worked perfectly.  Files are exported into PDF format again.

Comment 51

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/f294f9e327ac

Comment 52

[drichard]

Can this be merged into FF 41 and FF 42 too please?  FF 43 means having to wait until mid-December.  That's 4 months without a major feature working for our employees.  I really do not want to put them on ESR.

Comment 53

[Mike Conley (:mconley) (:⚙️)]

Hey drichard,

Just waiting on release management to make a call on Aurora/beta uplift.

Comment 54

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8641762 [details]
MozReview Request: Bug 1184604 - Lazily override printer output format on Linux if not already set. r?karlt

Early in the beta cycle, important regression, should only impact our GNU/Linux users, taking it.
Should be in beta 4, testing would be appreciated.

Comment 55

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/d00f8aacf0e6

Comment 56

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

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

Comment 57

[drichard]

QA:  Confirmed this is merged into FF41b4 and working. Thank you all.