Printing to PDF/PS/SVG defaults to a hidden (.name) filename

The default name is mozilla.ps/mozilla.pdf now. But the file extension is not persistent, it's mozilla.ps by default...

(Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090304 Fedora/3.0-1.beta2.fc11 Thunderbird/3.0b2)

I see this bug as well, in Firefox (both 3.0.x and mozilla-central) and in Thunderbird (3.0b3pre).

From my experience, this bug became an issue when I upgraded to Ubuntu Jaunty. I think it might be a bug in newer versions of the GTK library.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.10) Gecko/2009042523 Ubuntu/9.04 (jaunty) Firefox/3.0.10
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090519 Minefield/3.6a1pre
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b5pre) Gecko/20090515 Shredder/3.0b3pre

My buggy machine has GTK version 2.16.1-0ubuntu2.
A different NON-buggy machine (running Hardy I think) has GTK version 2.12.9-3ubuntu5

(gtk versions obtained via "apt-cache show libgtk2.0-common | grep Version")

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

In a fresh profile, that "url.get()" call yields something like "file:///your/working/directory/mozilla.ps". (and yet that value is lost at some point -- we still run into this bug)

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".

I'm not sure how to debug this further -- I haven't hooked up GDB to step through the GTK library's code before, and I'm not immediately sure what I'd need to do for that.

Martin and Matej, would you mind providing your GTK library versions on the machines where you get the broken & working results (respectively) in comments 0 and 1?

Works fine for me with gtk2-2.14.7-7.fc10.i386 and I can't find the buggy version.

(In reply to comment #5)
> Works fine for me with gtk2-2.14.7-7.fc10.i386

Ok, that still makes sense -- that's a lower version-number than the first broken version we know of (2.16.1, from comment 2).

FWIW, this bug persists in Ubuntu 9.10 "Karmic", with libgtk version 2.18.3-1.
(using latest mozilla-central nightly as my browser)

Broken with gtk2-2.18.3-19.fc12.x86_64 on Fedora/Rawhide (soon-to-be Fedora 12)

Also broken on openSUSE 11.2 (gtk2-2.18.1)

This bug is particularly egregious because, if the user accepts the default filename (~/.ps), the resulting output file is (a) hidden, and (b) buried amongst scores of other hidden configuration files that begin with "." in the user's home directory.

FWIW: this bug affects gedit 2.28.0 in Ubuntu 9.10, too.

Can we get a bug filed upstream with gtk+ on this?

Works fine here with gedit-2.28.0-1.fc12.x86_64 and gtk2-2.18.4-3.fc12.x86_64 on Fedora 12, but it is broken with firefox-3.5.5-1.fc12.x86_64 and xulrunner-1.9.1.5-1.fc12.x86_64

I'll file an upstream bug.

Filed: https://bugzilla.gnome.org/show_bug.cgi?id=603823

Just posted a simple GTK program to demonstrate the issue (& that it's not Firefox-specific) on the upstream bug.

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

In fact the Firefox print dialog does not seem to work at all like the print dialog in other Gnome applications:

Example:
1. In Firefox, the default file type is PostScript, while in Gedit it is PDF.
2. In Firefox the default file name is empty ".ps", while in Gedit it is "print.pdf".
3. In Firefox, the print dialog does not remember any settings unlike the dialog in Gedit. If you for example choose in the Firefox dialog to make a two-sided print, nothing of it is left when you restart Firefox. In Gedit every change to any optio is saved - if you once choose to e.g. make a two-sided print, all prints will be two-sided until the option is changed again.

In my opinion Firefox should implement the print dialog in the same way as other Gnome/GTK apps do. The behaviour of e.g. Gedit is more correct and closer to the principles for example described in the Gnome User Interface Guidelines.

Should I file new bugs for each of these items?

You should file new bugs on #1 & #3. Don't file a new bug on #2, though, because that's this bug here. :)

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

As I have mentioned here: https://bugzilla.gnome.org/show_bug.cgi?id=603823#c5
this bug only happens when the default print to file is changed to ps or svg.

If my patch to change the default to pdf (like all other gnome apps) is applied this bug will be resolved as a side affect.
https://bugzilla.mozilla.org/show_bug.cgi?id=539426

Whats the best way to get the patch reviewed?

Patch for pdf as default checked in to mozilla central. Marking as fixed.

I am running Shredder. I updated my source tree with "python client.py checkout" yesterday afternoon, well after the comment above claiming that this has been fixed, and then rebuilt Thunderbird. The rebuilt Thunderbird is still defaulting to the file name ".ps" when I go to print an email message and then select "Print to File", so this does not seem fixed to me.

@Jonathan

Before "claiming" that someones work is incorrect please mark sure your own is correct first. The fact that you still have ".ps" should have been your first clue as the patch that was committed would have at a minimum change that to ".pdf"

Please try rebuilding after running a 'make clean' and make sure all other instances of Thunderbird are closed before running your new build.

Same result after "make -f client.mk clean" and rebuilding.
Same result from http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2011-09-26-03-00-17-comm-central/thunderbird-9.0a1.en-US.linux-x86_64.tar.bz2.
I am doing my best to be helpful. The rudeness is uncalled for. https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

I have checked out the thunderbird source freshly tonight and tested it on two machines with different gtk versions.
Also the nightly build you directed me to also worked correctly.

I think I may just have found the answer though. I'm using Ubuntu as my test machine and for some reason the print dialog does not remember the last settings that were used with Firefox/Thunderbird (I've seen this in a bug report somewhere) however testing with other Gnome apps if I change the output type to PostScript then print. If I open the dialog again then my setting is remembered and used as the default which causes this bug to happen once again (which I assume is happening to you). Looks like the gtk bug must be fixed to completely solve this bug. I will dig deeper into the gtk code tomorrow.

Note: Any rudeness was just being reciprocated, I apologies if it was unintentional.

Just to add another data point -- this is WORKSFORME in a *fresh* Firefox profile. However, I have the same results as Jonathan in my normal (non-fresh) Firefox profile -- that is, in my normal profile, print-to-file still defaults to the name ".ps", and when I tick "PDF", it suggests the filename ".pdf". (not mozilla.ps/mozilla.pdf)

And I can confirm what Timothy says in Comment 25 about Firefox not remembering the last printed-to filetype. My normal profile always suggests PS regardless of what I printed last, and a fresh profile always suggests PDF.

(Not sure why my normal profile is stuck wanting to print to PS. I can investigate more, but I'll hold off for now since it sounds like Timothy is on top of it.)

Mozilla/5.0 (X11; Linux x86_64; rv:9.0a1) Gecko/20110926 Firefox/9.0a1

Hi Daniel,
          Thanks for the feedback. Feel free to look into why your profile is stuck defaulting to PS as I can't reproduce this on either of my Linux machines.

As for the GTK issue I have submitted a patch over at the gnome bugzilla https://bugzilla.gnome.org/show_bug.cgi?id=603823 that resets the lost value (this fixes the bug for all test cases on my machine). However this is a strange bug and my patch only cleans up the mess that is created from the change notifications, my guess is something could be done to clean these notifications up however I don't currently have the experience with GTK to do it myself.

(In reply to Timothy Arceri from comment #27)
> Hi Daniel,
> Thanks for the feedback. Feel free to look into why your profile
> is stuck defaulting to PS as I can't reproduce this on either of my Linux
> machines.

Oddly, it fixed itself in the past few days -- not sure what was going on. During that time, I reinstalled my OS (upgrading to Ubuntu 11.10beta2), though I kept my Firefox profile intact -- the upgrade may have reset some internal piece of Gnome state that was causing trouble.

So, this is WORKSFORME in my normal Firefox profile now.

Jonathan, can you still reproduce this bug (in a recent Firefox or Thunderbird build off of m-c)?

(In reply to Daniel Holbert [:dholbert] from comment #28)
> Jonathan, can you still reproduce this bug (in a recent Firefox or
> Thunderbird build off of m-c)?
Yes.
Still broken for me as of 10.0a1 (2011-09-30).

Jonathan: thanks -- so presumably there's something "stuck" in your Firefox profile that's making you default to Postscript. If possible, it'd be helpful if you could isolate whatever's doing that by doing something like the following:
  (1) backup your profile (tar czvf ~/backup.tar.gz ~/.mozilla/firefox/[your_profile_folder])
  (2) extract that backup to a temporary directory
  (3) delete chunks out of that temporary directory until you've isolated the file (or piece of the file) that triggers the bug.

(I'm guessing it's a line in "prefs.js" that's responsible, but I can't be sure)

I'm encountering the problem with TB, not FF.
I removed a bunch of "print_to_filename" preferences from prefs.js and that made the problem go away.
When I printed to a file after removing those preferences and then exited from TB, new "print_to_filename" preferences were not saved in prefs.js.
This suggests to me that these "print_to_filename" resources are obsolete. If so, then shouldn't part of this fix involve removing them, at least during a transition period? Otherwise, every user encountering this problem is going to have to use the advanced configuration editor or a text editor to remove them manually from prefs.js, which doesn't sound to me like something we want to be telling end users they need to do.

(In reply to Jonathan Kamens from comment #31)
> I'm encountering the problem with TB, not FF.
(oops, sorry, I forgot about that)

> I removed a bunch of "print_to_filename" preferences from prefs.js and that
> made the problem go away.

Ah -- thanks, that's very helpful!

> When I printed to a file after removing those preferences and then exited
> from TB, new "print_to_filename" preferences were not saved in prefs.js.
> This suggests to me that these "print_to_filename" resources are obsolete.

I don't think "obsolete", but they might be only set under certain not-straightforward circumstances. (lots of printing prefs fall into this category, sadly.)

> If so, then shouldn't part of this fix involve removing them, at least
> during a transition period?

Possibly.

(In reply to Daniel Holbert [:dholbert] from comment #32)
> > If so, then shouldn't part of this fix involve removing them, at least
> > during a transition period?
>
> Possibly.

Perhaps we could add a special case, so that when this pref is read, we could just check if its value begins with a "." -- and if it does, then ignore( & clear?) it and use the default value. I doubt there are any users who actually want to print-to-file using a filename that starts with a "." (and if there are, we'd still allow them to, but their last-printed-filename just wouldn't get saved.)

(In reply to Daniel Holbert [:dholbert] from comment #33)
> Perhaps we could add a special case, so that when this pref is read, we
> could just check if its value begins with a "."

But the settings I removed _didn't_ have values starting with ".". They were full paths. For example, one of them was "/home/jik/mozilla.ps".

  jik

Ah, ok. That's odd then - you might be right about them being obsolete, and I also don't understand how those prefs tie into triggering this bug. :( It might initially seem that a PS path in that pref would trigger PS behavior which triggers this bug -- but that's not the case in my profile. I have two "print_to_filename" prefs, and they're both full paths of PS files (not PDF files), and yet I default to PDF files.

It might be good to just resolve this bug here as FIXED and file a new one to track remaining issues arising from interactions with "stale" prefs in existing profiles.

(In reply to Daniel Holbert [:dholbert] from comment #35)
> It might be good to just resolve this bug here as FIXED and file a new one
> to track remaining issues arising from interactions with "stale" prefs in
> existing profiles.

I don't see what good that would do.

This bug, as-filed, is fixed (in a fresh profile), by changing the default print target to PDF.

There's apparently a mysterious separate issue with state in existing profiles that makes Firefox default to PS and hit this bug.

Right now this bug has a mixture of comments about both of these issues, but they're really separate issues (albeit with the same result).

I'm proposing that we close this bug, since the original issue is fixed (per comment 21) and file a followup to track/investigate the second issue. I'll file that bug.

Per previous comment, I'm re-marking this bug as FIXED, based on the belief that any remaining issues arise from stale data in profiles, which we're now tracking in bug 691430.

My patch for the upstream GTK+ bug causing this problem has been committed https://bugzilla.gnome.org/show_bug.cgi?id=603823

This bug should probably be closed as invalid or wontfix as its not actually a bug with mozilla but rather a GTK bug.

Thanks, that's great news!

I believe "INVALID" (meaning "not a mozilla bug") is the correct resolution for that. However, it's probably best to verify that it's actually fixed (for Firefox) in a patched GTK version first.

Perhaps you've already done that? If not, we can wait 'til patched GTK versions make it to distros, and resolve this at that point.

I have tested the patched GTK against Firefox 8 and it displays the full file name. It is in no way Firefox bug

Awesome. Resolving as INVALID then, since that's what I recall us using for issues that turn out to be bugs in external programs.

Hopefully the GTK fix makes it out to users soon!