I observed the following nautilus crash below after trying to access an SMB
share and mistyping my password (it also happens if mounting the SMB share
fails for other reasons after entering a password). The crash happens when
the password entry window pops up the second time, in this code path, at
the 7th element of priv->user_widgets:
458 pw_dialog_anonymous_toggled (GtkWidget *widget,
459 GtkMountOperation *operation)
460 {
...
472 for (l = priv->user_widgets; l != NULL; l = l->next)
473 {
474 gtk_widget_set_sensitive (GTK_WIDGET (l->data), !priv->anonymous);
475 }
The broken element had l->data = 0xaaaaaaaaaaaa, which means the pointer had
been freed.
The broken list entries were at the of the list because when
gtk_mount_operation_ask_password_do_gtk() constucts the pop-up the 2nd time,
it prepends new widgets:
gtk_mount_operation_ask_password_do_gtk()
table_add_entry
operation->priv->user_widgets = g_list_prepend (operation->priv->user_widgets, entry);
The problem is that in pw_dialog_got_response(), the widget is destroyed,
which also destroys all child widgets, but the priv->user_widgets list is
neither freed nor set to NULL.
Fix it.
When asking for a password, the message string is split on primary
and secondary if it contains a newline character. However, the newline
character is currently part of both strings, which creates weird
spacing between the GtkLabels. I suppose this is bug, which was not
visible as in most cases (if not all) the message string hasn't
contained the new line characters so far. But we are going to change
that now, see GNOME/gvfs!82. Let's drop the new line character similarly
as it is done when asking for a question, or showing processes in order
to fix the weird spacing.
GMountOperation now supports options to unlock TCRYPT volumes. This
patch sets these options if they are returned by AskPassword() of a
GtkMountOperationHandlerProxy.
Attached widgets inherit from the style of the widget they are
attached to. This can sometimes have unintended consequences,
like a context menu in the main view of gedit inheriting the font
that is configured for documents, or the context menu of the preview
in the font chooser coming up with humongous font size.
To fix this problem, we introduce a context menu style class
and use it for all menus that are used like that. The theme
can then set a font for this style class.
https://bugzilla.gnome.org/show_bug.cgi?id=697127
We've recently a number of classes wholly. For these cases,
move the headers and sources to gtk/deprecated/ and adjust
Makefiles and includes accordingly.
Affected classes:
GtkAction
GtkActionGroup
GtkActivatable
GtkIconFactory
GtkImageMenuItem
GtkRadioAction
GtkRecentAction
GtkStock
GtkToggleAction
GtkUIManager
This improves the layout of the mount operations dialog to:
* Make primary labels bold in all cases
* Lay out the widgets in a grid
* Put space between the two radio groups to distinguish them
https://bugzilla.gnome.org/show_bug.cgi?id=682552
Make GMountOperation look for an owner of org.Gtk.MountOperationHandler
if possible, and use it instead of the GTK-based dialogs.
This allows applications to use the implementation offered by the
desktop shell, if available, through a DBus private interface:
org.Gtk.MountOperationHandler.
https://bugzilla.gnome.org/show_bug.cgi?id=674963
Add _gtk_button_event_triggers_context_menu() and use it instead
of checking for event->button == 3, so context menus are invoked
correctly on the Mac.
This commit was created using a script that searched for all docstrings
containing a parameter and the string 'or %NULL'.
Gdk backends and demos excluded as they are not part of a public API
https://bugzilla.gnome.org/show_bug.cgi?id=610474
2009-03-10 Alexander Larsson <alexl@redhat.com>
* gtk/gtkmountoperation.c:
(gtk_mount_operation_ask_password):
Clear all optionally created widget pointer in priv. Initially
priv is cleared so thats ok, but on a second call we may have
leftovers from previous calls which is problematic if for instance
we asked for the user the first time and not the second, then we
will access the old priv->username_entry.
svn path=/trunk/; revision=22496