GNOME Bugzilla – Bug 510303
gpg signing dialog is missing text in 2.21.5
Last modified: 2013-09-13 00:58:01 UTC
when gpg signing a message, the phrase in the dialog is missing in evolution 2.21.5, see the screenshot. this hasn't happened earlier. i get the following output on the terminal: (evolution:26000): Gtk-WARNING **: Failed to set text from markup due to error parsing markup: Error on line 2 char 29: Odd character '@', expected a '>' or '/' character to end the start tag of element 'ak-47', or optionally an attribute; perhaps you used an invalid character in an attribute name (evolution:26000): Gtk-WARNING **: Failed to set text from markup due to error parsing markup: Error on line 2 char 29: Odd character '@', expected a '>' or '/' character to end the start tag of element 'ak-47', or optionally an attribute; perhaps you used an invalid character in an attribute name looks like something's wrong with the parsing (iirc the string contains the name of the account used, in this case <ak-47@example.com>).
Created attachment 103103 [details] screenshot
i wonder if it's a side effect of bug 506250. adding matt to the CC.
Created attachment 103105 [details] screenshot of 2.12 dialog
Bah, I forgot to make sure the user and host names are properly escaped when generating the markup to be used in the password dialog. Easy fix, no string change required.
Fixed in revision 8392. http://svn.gnome.org/viewvc/evolution-data-server?view=revision&revision=8392
Created attachment 103112 [details] [review] Proposed patch Not so fast, Matt. Previous commit was correct but incomplete, and doesn't actually address Andre's issue. There's a few more strings in Camel that need to be escaped, especially the error messages about previous authentication attempts. Same solution as before but this patch is a bit more involved, so I'll post it for review. The last hunk of the patch should address Andre's issue.
For the record, this bug is actually a side-effect of bug #503400. The top label of the password dialog now treats all text as markup, so anything that can appear in that label has to be properly escaped for the markup parser.
patch in comment #6 fixes my issue.
Matt, commit it please.
Committed to trunk (revision 8402).
*** Bug 513409 has been marked as a duplicate of this bug. ***