GTK bug in the print dialog

[Mike Hommey]

reassign -1 libgtk2.0-0
tag -1 +patch

Hi,

So after some reproduction and deeper analysis, this looks like a
problem on the GTK end. (BTW, this does happen with upstream firefox
builds, contrary to what sylvestre said: I could reproduce)

This is what happens:
- The gtk print dialog is set up by iceweasel and shown up.
- When selecting the "Print to File" option, a bunch of things happen,
  one of which is invoking update_widgets in
  gtk/gtkprinteroptionwidget.c.
- The relevant code for this case is:
    case GTK_PRINTER_OPTION_TYPE_FILESAVE:
      {
        gchar *filename = g_filename_from_uri (source->value, NULL, NULL);
        if (filename != NULL)
          {
            gchar *basename, *dirname, *text;

            basename = g_path_get_basename (filename);
            dirname = g_path_get_dirname (filename);
            text = g_filename_to_utf8 (basename, -1, NULL, NULL, NULL);

            if (text != NULL)
              gtk_entry_set_text (GTK_ENTRY (priv->entry), text);
            if (g_path_is_absolute (dirname))
              gtk_file_chooser_set_current_folder (GTK_FILE_CHOOSER (priv->combo),
                                                   dirname);
            g_free (text);
            g_free (basename);
            g_free (dirname);
            g_free (filename);
          }
        else
          gtk_entry_set_text (GTK_ENTRY (priv->entry), source->value);
        break;
      }
- In the above code, basename and dirname get proper values.
- When gtk_entry_set_text is called, it ends up calling
  filesave_changed_cb from gtk/gtkprinteroptionwidget.c through some
  signal.
- filesave_changed_cb sets the uri as a print option, derived from the
  directory value is gets from gtk_file_chooser_get_filename... which
  returns null. With the directory being null, the uri is derived from
  from gtk_file_chooser_get_uri, which returns null too. With that being
  null, uri ends up being ''.
- The reason both gtk_file_chooser_get_filename and
  gtk_file_chooser_get_uri return null above is because
  gtk_file_chooser_set_current_folder has not been called yet, and it's
  called after, in that snippet from update_widgets.
- That gtk_file_chooser_set_current_folder call doesn't make that uri
  recomputed, so unless either the file name or the directory is fiddled
  with in the UI, the value returned for output-uri (gotten from the
  print option filesave_changed_cb stored) is wrong.
- The result of that is that when sending the job, gtk print doesn't
  save it besides the temporary file it creates.

The following patch solves the issue for me:

diff -ruN gtk+2.0-2.24.22.orig/gtk/gtkprinteroptionwidget.c gtk+2.0-2.24.22/gtk/gtkprinteroptionwidget.c
--- gtk+2.0-2.24.22.orig/gtk/gtkprinteroptionwidget.c   2013-10-05 07:02:29.000000000 +0900
+++ gtk+2.0-2.24.22/gtk/gtkprinteroptionwidget.c        2014-02-24 17:01:03.968343933 +0900
@@ -927,11 +927,11 @@
             dirname = g_path_get_dirname (filename);
             text = g_filename_to_utf8 (basename, -1, NULL, NULL, NULL);
 
-            if (text != NULL)
-              gtk_entry_set_text (GTK_ENTRY (priv->entry), text);
             if (g_path_is_absolute (dirname))
               gtk_file_chooser_set_current_folder (GTK_FILE_CHOOSER (priv->combo),
                                                    dirname);
+            if (text != NULL)
+              gtk_entry_set_text (GTK_ENTRY (priv->entry), text);
             g_free (text);
             g_free (basename);
             g_free (dirname);

The issue is likely fixed in gtk3 as a side effect of
https://bugzilla.gnome.org/show_bug.cgi?id=682129

Mike