More details from the mozilla bug page:
Quoting https://bugzilla.mozilla.org/show_bug.cgi?id=485067#c3
> Here's the line of Mozilla code that comes into play here:
> 
> > 460   gtk_print_settings_set(mPrintSettings, GTK_PRINT_SETTINGS_OUTPUT_URI, url.get());
> http://mxr.mozilla.org/mozilla-central/source/widget/src/gtk2/nsPrintSettingsGTK.cpp#460
> 
[snip]
> I've tried replacing the "url.get()" token there with some hard-coded string
> constants, and I've learned the following -- it looks like we hit this bug
> whenever we pass in a string that contains a colon character.  When I exclude
> the colon, then the print dialog ends up using the correct filename (albeit
> with no path information).
> 
> e.g. "/random/directory/foo.ps" and "file///random/directory/foo.ps" both end
> up presenting print dialogs that offer to save "foo.ps" in the current working
> directory.  And if I add a colon (yielding "file:///random/directory/foo.ps"),
> then the print dialog buggily reverts to naming the file ".ps".

Note also that GTK's documentation for the "GTK_PRINT_SETTINGS_OUTPUT_URI" specifically states that "file://" URIs are supported:
http://library.gnome.org/devel/gtk/unstable/GtkPrintSettings.html#GTK-PRINT-SETTINGS-OUTPUT-URI:CAPS

Created attachment 149130 [details]
simple program that demonstrates problem

The attached simple program demonstrates the problem.

I can compile it on Ubuntu 9.10 with this command:
> g++ simple-gtk.cpp -o simple-gtk `pkg-config gtk+-2.0 --cflags --libs` -I /usr/include/gtk-unix-print-2.0/

It presents a list of buttons, each of which generates a print dialog with the button's label passed in as GTK_PRINT_SETTINGS_OUTPUT_URI.

The values beginning with "file:/" all exhibit this bug -- they end up with the suggested filename being ".ps".

The other values are fine -- they appear to use everything after the last "/" character. (which is reasonable behavior)

(In reply to comment #2)
> The other values are fine -- they appear to use everything after the last "/"
> character. (which is reasonable behavior)

Just for completeness, the exception to the above statement is "foo:///tmp/nonfile_path_with_colon.ps" -- given that value, the print-dialog uses the full value (including "foo:///") as its suggested filename.  (This is still reasonable behavior, since that this is silly "foo://" URI.  The behavior I'd like to see changed/fixed is for file://, the format this dialog is supposed to support. :))

Maybe related with this bug: https://bugzilla.gnome.org/show_bug.cgi?id=587053

Created attachment 196862 [details]
Sample application that works with gtk3

I have tested this in GTK 3 and the problem is not will the colon but with this setting:
 gtk_print_settings_set(printSettings, GTK_PRINT_SETTINGS_OUTPUT_FILE_FORMAT, "ps");

When the file format is left unset the URI works correctly. Something is going wrong when file format is set to "ps" or "svg" if its set to pdf the uri is fine.

I've attached a new test file that works with GTK 3. To build it:

g++ simple-gtk3.cpp -o simple-gtk `pkg-config gtk+-3.0 --cflags --libs` -I /usr/include/gtk-3.0/unix-print

ok here is what is happening there is a function file_printer_output_file_format_changed in gtkprintbackendfile.c 
When "Print to File" is selected this method is called twice. The first time the lookup of uri_option returns the correct value e.g "file:///home/timothy/mozilla.ps" the second time it returns "" the question is why is this being called twice and what data is being passed to it?

I can make a patch with a work around to ignore blank strings but it would be better if I (or someone else) can find the cause of the second call.

On the first call the format is set to "pdf", and on the second call its set to "ps" this it where the uri data is lost.

Created attachment 197556 [details] [review]
Fix for lost uri

Ok so whats happening is when the format type is changed this triggers "file_printer_output_file_format_changed" to be called, and at the end of this "gtk_printer_option_set" is called which triggers a change which is intended to update the GUI (I think) however this also triggers "file_printer_output_file_format_changed" to be called again. I'm not sure how this could be implemented without the need for this circular calls happening (maybe it cant) as this is really my first time working with GTK.

I do however have a patch which reapplies the uri value that gets lost during the cycle.

Also just to bump up the importance of this bug, Firefox is not the only application affected. As far as I can tell all Gnome apps that use this feature are.

Steps to Reproduce:
1. Use Print to File to print in PostScript format rather than pdf
2. Open the print to File dialog again and now suggested output is ".ps"

Thanks for the patch, but I don't think it will be committed as-is. You'd need to find out why the URI is erased in the first place by file_printer_output_file_format_changed(), which AIUI shouldn't happen. Good luck! ;-)

Created attachment 200156 [details] [review]
Fix lost filename 

Ok found the cause of the problem. The widget was creating an event before it had finished updating all the values. Please let me know if I've used the right blocking functions here, Thanks.

Yes, those are the correct functions to block the signal emission.

One other thing - in that patch, the call to gtk_file_chooser_set_current_folder() should really be gtk_file_chooser_set_filename().  (This is not a problem with your patch per se; it's a problem with the original code.)  The file chooser button is used in SELECT_FOLDER mode, and the code intends to set the selection - not the "folder in which the selection lives", which is what gtk_file_chooser_set_current_folder() is about.

Created attachment 200472 [details] [review]
Fix lost filename v2

Updated fix with suggestion to change gtk_file_chooser_set_current_folder to gtk_file_chooser_set_filename

Please review

@Federico, Milan

Is one of you able to review my latest patch and let me know if I need to change anything to get it committed. It would be good to finally have this issue resolved.

Thanks

Sorry, I've no authority to review your patch, and I've even no way of testing it ATM. :-/ From a purely stylistic POV it looks good to me, and your reasoning makes sense, but... Don't worry, though, somebody will probably review it.

I think you should ping e.g. mclasen on #gtk+ on irc.gnome.org.

Review of attachment 200472 [details] [review]:

Makes sense to me, and works fine in my testing.

Thanks for the review. Can someone push the patch to git master for me as I don't have git access.

Created attachment 203038 [details] [review]
print to file: fixed lost filename in gui

Stop widget creating an event before updating both directory and
filename values.

Attachment 203038 [details] pushed as 36effbb - print to file: fixed lost filename in gui

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

Reopening with request for this to be applied to the 2.24 branch. I will apply a fresh patch that fixes so whitespaces

Created attachment 256770 [details] [review]
Fix print to file filename

Fixes whitespaces in previous patch

bump. Can someone commit this to the 2.24 branch?

Closing again as this is pretty much obsolete if the fix for https://bugzilla.gnome.org/show_bug.cgi?id=554712 is back ported to gtk2