485067 - "Print To File" filename defaults to just ".ps" or ".pdf" with libgtk versions >= 2.16

Status: RESOLVED INVALID

Description

[Matěj Cepl]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; cs-CZ; rv:1.9.0.7) Gecko/2009030503 Fedora/3.0.7-1.fc10 Firefox/3.0.7
Build Identifier: firefox-3.1-0.7.beta2.fc11.x86_64

When you tell thunderbird 3 beta that you want to print to a file, it pops up a
dialog whose default file name is ".ps".  It should have a reasonable default
file name.  Something based on the Subject line might be useful, or perhaps
just "email.ps", but ".ps" is right out.

Also, the settings for this dialog should persist between invocations.  I.e.,
if I print a message to a file in a particular directory in PDF format, then
the next time I print to a file in the same thunderbird session, PDF format
should be selected and it should be in the same directory I printed into
before.  



Reproducible: Always

Steps to Reproduce:
1.see above
2.
3.

Comment 1

[Martin Stránský [:stransky]]

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)

Comment 2

[Daniel Holbert [:dholbert]]

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

Comment 3

[Daniel Holbert [:dholbert]]

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.

Comment 4

[Daniel Holbert [:dholbert]]

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?

Comment 5

[Martin Stránský [:stransky]]

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

Comment 6

[Daniel Holbert [:dholbert]]

(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)

Comment 7

[Matěj Cepl]

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

Comment 8

[Wolfgang Rosenauer [:wolfiR]]

Also broken on openSUSE 11.2 (gtk2-2.18.1)

Comment 9

[Daniel Holbert [:dholbert]]

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.

Comment 10

[Daniel Holbert [:dholbert]]

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

Comment 11

[Reed Loden [:reed] (use needinfo?)]

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

Comment 12

[Matěj Cepl]

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

Comment 13

[Daniel Holbert [:dholbert]]

I'll file an upstream bug.

Comment 14

[Daniel Holbert [:dholbert]]

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

Comment 15

[Daniel Holbert [:dholbert]]

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

Comment 17

[Otto Kekäläinen]

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?

Comment 18

[Daniel Holbert [:dholbert]]

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

Comment 20

[Timothy Arceri]

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?

Comment 21

[Timothy Arceri]

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

Comment 22

[Jonathan Kamens]

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.

Comment 23

[Timothy Arceri]

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

Comment 24

[Jonathan Kamens]

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

Comment 25

[Timothy Arceri]

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.

Comment 26

[Daniel Holbert [:dholbert]]

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

Comment 27

[Timothy Arceri]

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.

Comment 28

[Daniel Holbert [:dholbert]]

(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)?

Comment 29

[Jonathan Kamens]

(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).

Comment 30

[Daniel Holbert [:dholbert]]

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)

Comment 31

[Jonathan Kamens]

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.

Comment 32

[Daniel Holbert [:dholbert]]

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

Comment 33

[Daniel Holbert [:dholbert]]

(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.)

Comment 34

[Jonathan Kamens]

(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

Comment 35

[Daniel Holbert [:dholbert]]

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.

Comment 36

[Jonathan Kamens]

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

Comment 37

[Daniel Holbert [:dholbert]]

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.

Comment 38

[Daniel Holbert [:dholbert]]

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.

Comment 39

[Timothy Arceri]

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.

Comment 40

[Daniel Holbert [:dholbert]]

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.

Comment 41

[Timothy Arceri]

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

Comment 42

[Daniel Holbert [:dholbert]]

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!