After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 336574 - Personal Contacts with JPEG Photo Display
Personal Contacts with JPEG Photo Display
Status: RESOLVED DUPLICATE of bug 433782
Product: evolution
Classification: Applications
Component: Contacts
2.6.x (obsolete)
Other All
: Normal normal
: ---
Assigned To: Srinivasa Ragavan
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2006-03-30 05:44 UTC by Ryan Shea
Modified: 2013-09-10 14:04 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14

Attachments
proposed patch (2.12 KB, patch)
2007-05-03 16:53 UTC, Milan Crha 		none Details | Review

Description Ryan Shea 2006-03-30 05:44:52 UTC 
Please describe the problem:
Contacts imported from a VCARD v3 with JPEG photos take a very long time both to
import and to display.  Evolution will lock up for nearly a minute to display
one of these contacts.

Steps to reproduce:
1. Import a VCARD with a jpeg photo (you may use
http://www.muppethouse.com/JaneDoe.vcf if you like)
2. Add a few more contacts
3. Click on the recently added contact with the photo


Actual results:
CPU Spikes and the program becomes unresponsive for around one minute

Expected results:
Contact is displayed in a usable timeframe and the application does not lock up.

Does this happen every time?
Yes

Other information:
Comment 1 André Klapper 2006-03-30 10:13:09 UTC 
we don't support vcard3 entirely (bug 240756), but evo shouldn't become unresponsive, sure.
Comment 2 Sushma Rai 2006-04-07 04:17:47 UTC 
Need to resize the image, as we do while adding an image to the contact.
Comment 3 Ryan Shea 2006-04-07 04:21:13 UTC 
The original vcards imported that caused this problem were exported from Apple's Address book and that is the size they were stored in.
Comment 4 André Klapper 2006-04-26 19:27:57 UTC 
harmonizing target milestone
Comment 5 Milan Crha 2007-05-03 16:53:10 UTC 
Created attachment 87467 [details] [review]
proposed patch

Main problem was in e_vcard_to_string_vcard_30 when cutting lines longer then 75 characters.
I changed it to allocate new buffer big enough to store there whole cut text and then simply appending text from old buffer to new one with CRLF and space characters. It produces same output like old algorithm. I tested it even with UTF8 characters (in notes).
Comment 6 Milan Crha 2007-05-04 07:23:46 UTC 
I found that other patch has been made in bug #433782 in the same place as I did.
Comment 7 Srinivasa Ragavan 2007-05-12 09:23:11 UTC 
Im closing this as an dupe of bug #433782 as the reasons are same. Will be fixed in 2.11.2

*** This bug has been marked as a duplicate of 433782 ***