845425 - Print to file ignores specified directory

Status: RESOLVED INVALID

(Core :: Printing: Output, defect)

Description

[cloos]

With ff 19 and sm 2.16, when I print to a file the directory I specify is ignored and the output file is written to the process’s $CWD.

Perhaps as another symptom of the underlying problem, when one first chooses print to file on the print dialog, the directory is blank.  It used to be $HOME, IIRC.

This worked properly at least as recently as the last non-beta version, maybe even as recently as during the betas.

(There are some old bugs complaining about the print to file functionality, but I didn’t find any new enough to be a regression report.)

Comment 1

[Mats Palmgren (inactive)]

WFM, Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0
Using a clean profile, File->Print..., click on Print to File,
the value of "Save in folder" is set to my home folder and "Name" contains
"mozilla.pdf".  Changing "Name" to "/tmp/mozilla.pdf" and clicking Print
creates the file under /tmp.

Reporter, please specify the exact steps you used to reproduce the bug.
Can you reproduce it with a clean profile?
(run for example: "mkdir /tmp/profile; firefox -profile /tmp/profile")

Comment 2

[cloos]

Choose a directory from the save in directory drop down and enter just a filename rather than a path in the text box.  The dropdown is ignored.

A rooted path works, but the fact that the 'save in directory' directory is ignored is still a regression.

A new profile wouldn’t/couldn’t have a set of saved target directories, and therefore is not a useful thing to consider.  And one certainly cannot expect anyone to dump all of their current profiles and create new ones just because one updated one’s ff and/or sm versions.

Comment 3

[cloos]

But for the hell of it I did try a new profile.

Doesn’t change anything.

And the saved dirs are obviously saved outside of the profile; the new profile had the same set as the existing files, so please ignore the first sentence of the last paragraph of comment #2.  Thanks!

Comment 4

[cloos]

[SIGH]

I have determined that this is a gtk+ issue, rather than a ’zilla issue.

(This bugz really needs a NOTZILLA resolution; none of the available values is really true here.)

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to cloos from comment #4)
> (This bugz really needs a NOTZILLA resolution; none of the available values
> is really true here.)

We generally include that under the umbrella of INVALID.  (invalid means "the behavior described isn't a bug in firefox/gecko", whether it's due to a typo in the testcase or a buggy external library.)

Comment 6

[Benjamin Kraus]

Related (Duplicate) Bugs: Bug 806357, Bug 845425, Bug 865416, Bug 923041
Bug 923041 seems like the most accurate description from my experience.
Bug 845425 concluded that it was a gtk+ issue, not Mozilla issue.

See also:
https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1213385
https://bugzilla.redhat.com/show_bug.cgi?id=888080