894966 - Print to File fails unless you type a file path in the filename field

Status: NEW

(Firefox :: General, defect)

Description

[Akkana Peck]

With Firefox 22: File->Print... Click on Print to File. You get a field for Name (defaulting to mozilla.ps) and a dropdown for Save in Folder (defaulting, on Linux, to your username; presumably this is meant to be the home directory, but there's no way of actually checking that since it doesn't show you a path).

Click Print. Firefox pops up a dialog and looks like it's generating a PDF.

Now look for the file in ~/mozilla.pdf. It's not there. It's not anywhere else, either; at least, updatedb followed by locate doesn't find anything named mozilla.pdf on the system.

Now bring up File->Print and Print to File again. This time, change the value of the Name field to ./mozilla.pdf (add a ./ at the beginning). Print. Voila! Now there's a file there in ~/mozilla.pdf.

Absolute paths work too -- e.g. you can print to to /tmp/mozilla.pdf or /path/to/somewhere/else/foo.pdf. You just can't leave it at the default -- you must add pathname components.

I don't remember having this problem prior to Firefox 22, but perhaps I've usually typed absolute pathnames since it's not easy to choose a directory using the dropdown.

Comment 1

[zxdvd_zhang]

Reproduced @
Firefox 23
Linux 3.7.10-1.16-desktop x86_64
opensuse 12.3
If I opened the dropdown list, then chose the filesystem->Home->"User name", it will generate the pdf file successfully.
It seems something wrong with the default home directory setting.

Comment 2

[Adam Nielsen]

I've just come across this problem too.  You don't have to change the folder name, you can change the filename also.  If you change it from "mozilla.pdf" to "mozilla2.pdf" then it will create ~/mozilla2.pdf without any problems.

But if you delete the file and print again, the filename field will remember "mozilla2.pdf" but it won't create ~/mozilla2.pdf any more.  You have to change the filename to something else (e.g. "mozilla3.pdf") and then it will work.

It seems like the destination filename/path is not being set until one of these fields are changed, so if you don't change the fields, some "onChange" handler is never called leaving the output filename as a blank.

Comment 3

[Trevor Cordes]

Yes, I just ran into this problem.  Firefox 25.0 for linux.

I will add that it appears you must change either field (the save directory or the file name) before it will save.  If you print-to-file a page, delete that file via shell or some gui tool, and immediately try to reprint the page in firefox with the same settings (it remembers the last path/filename you chose), it will not print the second time.

It *acts* like it is printing (showing the creating of tmp files and a status bar) but when done there is no resulting file.

I would wager, as a programmer, this is an extremely simple one-line bug to fix.

Comment 4

[Trevor Cordes]

I just discovered by accident this bug is probably not a firefox bug, but a GTK (or whatever toolkit firefox is using) bug because this bug also exists when I try to print from claws-mail.  It shows an identical print option dialog and has the exact same bug when you choose print-to-file.  We should search for this bug filed against GTK (or whatever) and link to it here for others to find before closing this as a firefox bug.

Comment 5

[Trevor Cordes]

Found one, see redhat bugzilla bug https://bugzilla.redhat.com/show_bug.cgi?id=1003198

This bug should be closed here and discussion moved to the above link, or similar bugs found on other sites.

Comment 6

[gregory]

I see this problem too (on Fedora 20):
gtk2-2.24.22-2.fc20.x86_64
firefox-31.0-1.fc20.x86_64
Mozilla Firefox 31.0
Interestingly enough, the Print to File works fine if Postscript is chosen as the format
(which may be related to this being rather an issue with GTK2). However, in this case the name
of the file to write to is not memorised/saved and when printing again only .ps appears in the name field of the Print -> General -> Print to File menu.

Comment 7

[Trevor Cordes]

This bug has long since been fixed by changes in the dialog.  Can be closed.