GNOME Bugzilla – Bug 619347
Decode QP in email in Contact List Editor
Last modified: 2011-05-13 11:28:20 UTC
Created attachment 161708 [details] Screenshot of misrendered address The documentation of this method claims to return the formatted name yet it previously encoded them in quotable strings. This is causing non-ASCII characters in address names to be displayed as quoted-printables in the UI and expands them as such in the address fields. I'll try to append a screen shot and a patch which fixes the issue for me.
Created attachment 161709 [details] [review] Patch candidate This Patch fixed the issue for me: [PATCH] Return formatted address in e_destination_get_address The documentation of this method claims to return the formatted name yet it previously encoded them in quotable strings. This patch fixes this which results in strings containing non ASCII characters to be rendered correctly in the UI. This also changes the vCard output but vCard 3.0 specifies that quotable-printable inline ecnodings have been eliminated. In any case this quoting should be handled in e_destination_export_to_vcard_attribute instead.
Sorry forgot to add a reference to the downstream bug report: https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/229187
I can't reproduce this problem in Evolution 2.30. Can you provide more exact reproducer steps, or maybe provide some sample addresses that are causing you problems?
1. Create a contact with the name: José Doe <jose@foo.bar> 2. Create a contact list 3. Add the José to the conact list That leads to the contact list to show the entry: =?ISO-8859-1?Q?Jos=E9?= Doe <jose@foo.bar> Please let me know if you need more information. PS: should I change the status to "UNCONFIRMED" when I add requested information like this?
Please let me know if you require an further examples like: Klaus Müller <kaete.kummer@foo.bar> Käte Kummer <kaete.kummer@foo.bar> I'll update the status to unconfirmed just in case that's required for this bug to show up in a filter list.
I managed to reproduce this with Evolution 2.30.1.2 on Debian, but not with Evolution 2.30.1.2 on Fedora. I manage the Fedora evolution package and I keep it as close to upstream as possible, so I know there's no Fedora patches related to this. That must mean the bug is caused by a Debian patch which Ubuntu copied. I'll see if I can track it down.
Actually I take that last comment back. I managed to reproduce it in Fedora now. It fails to display correctly when you autocomplete using the entry in the Members section of the Contact List Editor. Choosing the contact via the Select button and dragging the contact into the list both work fine.
Okay, now that I can reproduce this I can finally verify that your patch works and doesn't appear to cause unwanted side-effects in the rest of the app that I can see. Sorry this took so long. Patch committed to master and gnome-2-30 branches: http://git.gnome.org/browse/evolution-data-server/commit/?id=db8c986c4f06f0cb57de9bfa6982b4e78f0bb32a http://git.gnome.org/browse/evolution-data-server/commit/?h=gnome-2-30&id=26f8a8a067634837816e01bb6bfc283f3a953453
the change seems to create new issues, we backported it to evolution 2.28 in lucid and get bugs similar to https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/596531 now "Recipient addresses added from address book are being changed incorrectly after clicking send. The recipient address of these messages in my Outbox are badly formed and cannot be sent correctly. For example after selecting my address Mr. Allan John Kelly <allan.kelly@xxxxxxx.net> is correct in my compose message TO address box. After clicking send, viewing the message in Outbox, the TO bcx now has a reformatted corrupted address where the < symbol has been repositioned incorrectly : Mr.AllanJ <ohn Kelly allan.kelly@xxxxxxx.net>"
e_destination_get_address() is badly documented, but I see now that it -is- intended to return an encoded name and email address suitable for use in an email header. e_destination_get_textrep() exists for displaying addresses to the user. It uses camel_address_format(). So the Contact List Editor is at fault for calling the wrong EDestination function. I'm tempted to rename it something like e_destination_get_display_name() to better clarify its purpose. I'm reverting the patches in comment #8 and will reinvestigate the Contact List Editor.
Fixed properly on the Evolution side: http://git.gnome.org/browse/evolution/commit/?id=9a8b5041b60bc5136dd21efb2e07b1cb172bce12
Thanks! And sorry for the misleading patch.
*** Bug 621812 has been marked as a duplicate of this bug. ***
*** Bug 621762 has been marked as a duplicate of this bug. ***
Thanks everyone who worked on this but I need to reopen this issue since still exists with all versions of Evolution which I was able to test so far. That includes: Lucid 2.28.3-0ubuntu10.2 Maverick 2.30.3-1ubuntu7.3 Natty 2.32.2-0ubuntu4 Fedora 15 Alpha 2.91.6.2 The issue remains that creating a contact list with recipients with non-ASCII characters will expand incorrectly a) after this list is saved and reopened and b) when the list is used when sending mail.
Created attachment 185188 [details] Screenshot of Contact List Editor when Reopened after creation
The parsing issue mentioned in comment #9 has been fixed within bug #347520. Let's see the rest.
Hello Milan, I'm sure what you mean with "Let's see the rest." Are you requesting some information that has not been provided? Or are you announcing that you are starting to look into the issue? Please let me know if you need more information. Cheers, David
I apologize for badly chosen words. I meant to say that I'll look on this and keep this bug updated accordingly.
Created attachment 187755 [details] [review] evo patch for evolution; I managed to reproduce the issue easily, just create few contacts with encoded names (I tried all mentioned here, like quoted printable encoded, then also with a dot inside the name part) and then add then a new contact list. it seems fine, but closing the contact list and reopening makes the difference. This patch uses same function as the contact preview routine, to decode such address into name and address and then show it to a user, in a human readable form. Sending message to such contact list also works fine.
Created commit 8807321 in evo master (3.1.2+) Created commit 14bb78b in evo gnome-3-0 (3.0.2+)
Thanks a whole lot! I will try to test this as soon as possible! Please note that there was the same issue in the expansion of contact lists in mail headers. Has that also been resolved with this fix or should I open a new report?
(In reply to comment #22) > Please note that there was the same issue in the expansion of contact lists in > mail headers. Has that also been resolved with this fix or should I open a new > report? Mine 3.1.1 works fine with respect of sending to such list, as I wrote at the end of comment #20.