Closed Bug 1057308 Opened 11 years ago Closed 10 years ago

pdf file not saved

Categories

(Firefox :: Untriaged, defect)

Product:
Firefox
Component:
Untriaged
Version:
31 Branch
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: yugiohjcj, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release) Build ID: 20140806164912 Steps to reproduce: 1) Go to any web page (for example: https://www.mozilla.org/en-US/). 2) Try to print to a PDF file: File > Print... > Print to File > Print (you must not change any value in the print dialog) Actual results: The file should be saved into: "/home/[username]/mozilla.pdf". Expected results: Instead of that, the file is not saved at all. As a proof, you can try again the above steps and you will see that Firefox does not ask you for overwriting the file. It means that the first file has not been saved at all. Workaround: Each time you need to print to a PDF, the workaround I found is to do: File > Print... > Print to File > Save in Folder > Other... Then here you select the same folder (/home/[username]) than the default folder. Then you can click on "Print". The file is saved into: "/home/[username]/mozilla.pdf". Similar bug: A similar bug is: https://bugzilla.mozilla.org/show_bug.cgi?id=526811 But there is a big difference with this bug: Firefox remembers all my printing settings. They are correctly displayed in the user interface. It is just the final result which is wrong: The file is not saved at all. Remark: Printing to a PS file works fine. Probably because Firefox never remember the file name for a PS file, so I need to fill manually the value each time I need to print to a PS file.
(In reply to yugiohjcj from comment #0) > Actual results: > The file should be saved into: "/home/[username]/mozilla.pdf". Not necessarily. That highly depends on your distribution's presets; in my case (Fedora 20) that is NOT the proposal. Which distribution is this about? Did you file a bug report in your distribution's bugtracker?
Flags: needinfo?(yugiohjcj)
It is the Slackware 14.1 distribution. I have not filled a bug report to my distribution's bugtracker because the package is not provided by this distribution (I have built this package myself from Firefox source code). This is how I compiled Firefox: $ DIR="firefox-31.0" $ DESTDIR="/tmp/${DIR}" $ tar xvf ${DIR}.source.tar.bz2 $ patch -p0 < ${DIR}.patch $ cd mozilla-release $ export MOZILLA_OFFICIAL="1" $ export BUILD_OFFICIAL="1" $ export MOZ_PHOENIX="1" $ export MOZ_PACKAGE_JSSHELL="1" $ make -f client.mk build $ make -f client.mk install DESTDIR=${DESTDIR} $ ln -s /usr/bin/firefox ${DESTDIR}/usr/bin/mozilla $ cd - $ rm -rfv mozilla-release The patch applied to Firefox is only a patch affecting the ".mozconfig" file: diff -ruN mozilla-release.ori/.mozconfig mozilla-release/.mozconfig --- mozilla-release.ori/.mozconfig 1970-01-01 01:00:00.000000000 +0100 +++ mozilla-release/.mozconfig 2013-04-30 10:44:47.616557284 +0200 @@ -0,0 +1,32 @@ +. $topsrcdir/browser/config/mozconfig +ac_add_options --enable-official-branding +ac_add_options --prefix=/usr +ac_add_options --libdir=/usr/lib +ac_add_options --with-default-mozilla-five-home=/usr/lib/firefox- +ac_add_options --with-system-zlib +ac_add_options --enable-application=browser +ac_add_options --enable-default-toolkit=cairo-gtk2 +ac_add_options --enable-startup-notification +ac_add_options --enable-crypto +ac_add_options --enable-svg +ac_add_options --enable-canvas +ac_add_options --enable-logging +ac_add_options --enable-xft +ac_add_options --enable-webm +ac_add_options --enable-xinerama +ac_add_options --enable-optimize +ac_add_options --enable-reorder +ac_add_options --enable-strip +ac_add_options --enable-cpp-rtti +ac_add_options --enable-single-profile +ac_add_options --disable-gnomevfs +ac_add_options --disable-ldap +ac_add_options --disable-accessibility +ac_add_options --disable-crashreporter +ac_add_options --disable-debug +ac_add_options --disable-tests +ac_add_options --disable-pedantic +ac_add_options --disable-installer +ac_add_options --disable-mailnews +ac_add_options --disable-composer +ac_add_options --disable-profilesharing When you say that it depends on my distribution, I disagree. When I am looking to the Firefox user interface, regarding the default values in the fields of the printing dialog, I see that the file should be saved into "/home/[username]/mozilla.pdf" because I can see the filename and the folder where the file will be saved. So, when I print, the expected behavior is to save the file at "/home/[username]/mozilla.pdf" (exactly as the user interface tells me).
Flags: needinfo?(yugiohjcj)
I have some news about this bug: It seems to not be a Firefox bug but a GTK+ problem. Indeed, I have a similar behavior when I am using gimp-2.8.6 and I am doing: File > Print... > Print to File > Print Here again, the file should be saved into: "/home/[username]/gimp.pdf", but if I do not edit the fields, it is not saved at all. Using "ldd" on the Gimp binary tells me that Gimp is using GTK+ 2 but on the Firefox binary, I am unable to see the corresponding library. Do you know if Firefox is linked to GTK+ 1, 2 or 3?
GTK 2. Firefox 38.0.5: $ ldd libxul.so |grep -i gtk libgtk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 (0x00007fbdf4b09000)
Oh thank you, so: $ ldd /usr/lib/firefox-31.0/libxul.so [...] libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb323d000) [...] Here is my version of GTK+ 2: gtk+2-2.24.20. This is not the last release of GTK+ 2 [1] so maybe there is an incompatibility with this version and Firefox 31.0. What version of GTK+ 2 are you using? Can you verify that you do not have this bug? [1] http://ftp.gnome.org/pub/gnome/sources/gtk+/2.24/
> What version of GTK+ 2 are you using? libgtk2.0-0 2.24.25-3 from Debian stable. > Can you verify that you do not have this bug? (31.0esr and a recent Nightly) With a new profile, the pre-selected folder is the current directory, which is the directory with the Firefox, read-only for the user.
OK thank you. I have just created a new profile like you. The pre-selected folder is the home directory. But the bug is still there: When I click on the "Print" button, the file is not saved in the home directory. Have you verified what happens when you click on the "Print" button ? (Warning: You must not edit the "Save in Folder" field in this dialog box during your test because it is a workaround for this bug and you will not see the problem)
(In reply to yugiohjcj from comment #7) > Have you verified what happens when you click on the "Print" button ? A "Printing…" dialog appears and then disappears. This appears when opening the Print window without having changed the directory: ** (firefox:31878): WARNING **: GDBus.Error:org.freedesktop.DBus.Error.Spawn.FileInvalid: Cannot do system-bus activation with no user Related bugs: bug 245602, bug 720426. For Windows: bug 360923, bug 536465. Probably irrelevant: bug 454003, bug 475501.
Yes, I have the same behavior: The "Printing…" dialog appears then disappears (after the progress bar reaches 100%). But after that, the file "mozilla.pdf" should be stored into the home directory. And the bug is: The file is not stored at this location. I also get this error message that appears twice: ** (firefox:950): WARNING **: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Avahi was not provided by any .service files ** (firefox:950): WARNING **: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Avahi was not provided by any .service files So, maybe it is just a problem relative to the communication between Firefox and the dbus service, isn't it? I think that when you select a different folder it is a workaround for this bug because Firefox does not use dbus in this case to get the destination folder for the PDF file. But when you do not change the destination folder, Firefox uses dbus that is probably not correctly configured on my system. That is explaining the thing... Now, how to resolve: I don't know because I am not an expert of dbus.
A vaguely related GTK meta bug (only concerned choosing the file name, not path): https://bugzilla.gnome.org/show_bug.cgi?id=686927
Ubuntu 14.04 x32 with GTK version: libgtk-3-0:i38 3.10.8-0ubun i386 libgtk2.0-0:i3 2.24.23-0ubu i386 I don't experience this issue on Ubuntu and I don't have any Debian around to try and test on it. FF versions used: Build ID 20151223140742 - Mozilla/5.0 (X11; Linux i686; rv:43.0) Gecko/20100101 Firefox/43.0 Build ID 20160103030302 - Mozilla/5.0 (X11; Linux i686; rv:46.0) Gecko/20100101 Firefox/46.0 Can you please confirm that this behavior is still reproducible?
Flags: needinfo?(yugiohjcj)
Yes, this behavior is still reproducible on Slackware 14.1 and Firefox 39.0. But as I said previously, it is probably related to the GTK library because other programs depending on GTK have the same behavior. I am using: - gtk+-1.2.10 - gtk+2-2.24.20 - gtk+3-3.8.2
Flags: needinfo?(yugiohjcj)
Hello Karl, could you please take a look at this issue?
Flags: needinfo?(karlt)
I used to see this bug. IIRC there was no folder prefilled in the dialog but folder value was blank. I am not able to reproduce with GTK+ 2.24.28 and Firefox 44.0b8. I suspect this was fixed in GTK.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Flags: needinfo?(karlt)
Resolution: --- → WORKSFORME
(In reply to Karl Tomlinson (ni?:karlt) from comment #14) > IIRC there was no folder prefilled in the dialog > but folder value was blank. Actually IIRC I saw two different bugs in the past. The first bug was the blank folder. Then the folder was set, but the file did not save unless something was changed in the dialog, which could be as simple as switching to ps and back to pdf.
I confirm, upgrading from gtk+2-2.24.20 to gtk+2-2.24.28 keeping firefox-39.0 solves the problem. The problem is fixed.
You need to log in before you can comment on or make changes to this bug.