GNOME Bugzilla – Bug 322789
Cannot select an image smaller than 1KB for contact
Last modified: 2013-09-10 14:04:09 UTC
Please describe the problem: I am unable to select a very small jpg image (<1KB) for a contact in the address book. Images larger than about 1KB work fine. Steps to reproduce: 1. Create a JPG that is around 800B (compress really low, for example). 2. Try to select this image as the image for a contact. Actual results: The goatee man icon is selected. Not even just no image, it's the goatee man himself. Expected results: The selected image should be selected. Does this happen every time? Yes Other information: Ubuntu 5.10 (breezy) x86
hi, thanks for reporting this. hmm... if you do this after starting evolution from the shell, is there any valuable output? and... i really ask myself: is this useful to be fixed? when at all do people use such small images? setting to NEEDINFO, please REOPEN when answering. thanks. :-)
Created attachment 55400 [details] Example of an image that won't load 72x96 jpg at 25% compression.
There's absolutely no output on the commandline, just fails silently. I'd be happy to set some debug variable if you'd like. It's true that images might rarely be smaller than 1KB, but it's not unreasonable either. Considering that one might export a vCard file it's desirable to have the image be as small as possible.
andrew, it works perfectly here, you're image is used like a charm. running unstable evolution 2.5.2. so i cannot reproduce it. which evolution version do you use exactly?
evolution 2.4.1 gnome 2.12.1 This is a standard Ubuntu install + updates + official backports. Could be a distro bug, or a gtk or gnome bug. I'll be setting up Ubuntu's pre-release (dapper) sometime soon to try some other bugs. When I do I'll try this one as well. BTW: Behavior is the same whether I use the file chooser or drag-and-drop.
I just tried it on evo 2.5.2 on dapper. It's broken there too. I'll report the bug downstream.
ok, setting to NEEDINFO. would be cool if you could add the link to the ubuntu bug. thanks in advance. forgot to mention my distro, it's suse9.3.
Ubuntu bug about that: http://bugzilla.ubuntu.com/show_bug.cgi?id=20352 evolution prints that when trying to set a small image to as a contact picture: "e-utils-WARNING **: calling e_icon_factory_get_icon_filename with unknown icon_size value (48)"
that warning is nothing to do with this. The bug is... e-image-chooser.c:set_image_from_data (EImageChooser *chooser, char *data, int length) { gboolean rv = FALSE; GdkPixbufLoader *loader = gdk_pixbuf_loader_new (); GdkPixbuf *pixbuf; gdk_pixbuf_loader_write (loader, data, length, NULL); pixbuf = gdk_pixbuf_loader_get_pixbuf (loader); This pixbuf is null and the loader return true and the error is also null, when i printed. To me Looks like a Gdk bug.
Works for me on evolution 2.4.0 (suse 93) and 2.5.5 (suse10). Is this a problem with some specifis gdk-pixbuf version. I have tested this with 2.6.4 and 2.8.3 version of gdkpixbuf. Can you check which version of gdkpixbuf you are using.
Definitely a gdkpixbuf Bug , see http://bugzilla.gnome.org/show_bug.cgi?id=324667.
Can confirm this bug with Evo 2.5.91, gtk+ 2.8.12, GNOME 2.13.91. Additional information: After selecting the picture in comment 2, Evo *does* display an image in the preview. However, this is *not* the desired one. Strangely, the placeholder image is displayed -- the very same as in the Contect Editor with no image. REOPENing. This definitely is not needinfo. I don't know if this is an Evolution or GTK+ bug. Feel free to move over to the appropriate Product, if you are sure. However, please note the additional info above about the "wrong image being displayed", before doing so. Another note: A GTK+ issue might explain, why this is not an issue on SuSE 9.3 (as Andre uses), which ships with GNOME 2.10.x...
ok, moving it to gtk, as it definitely is not an evolution issue.
It is an evolution issue. Look at the bug cited in comment 11
For those who don't like to dig links for themselves: > Oh, I see now what is wrong. You need to call gdk_pixbuf_loader_close() when you have fed all data to it, then it will work.
Dude we are already calling gdk_pixbuf_loader_close. loader=gdk_pixbuf_loader_new(); gdk_pixbuf_loader_write(loader,data,len,&err); pixbuf=gdk_pixbuf_loader_get_pixbuf(loader); gdk_pixbuf_loader_close(loader, NULL); I think this is a gdk-pixbuf issue as it is not reproducible consistently. (It works perfectly for me). If it had been evolution issue this should have been reproducible consistently. May be some issue with specific gtk versions, so moving it back to gtk. Andrew: It was me who put up that bug link in comment 11, and me only moved this bug to gdk-pixbuf. What does that mean, i had looked at the solution given there and it didnt work. We already do whatever was given as a solution for the bug. So without knowing the whole picture please dont give statements like in comment #15.Thanks.
(In reply to comment #16) > Dude we are already calling gdk_pixbuf_loader_close. > > loader=gdk_pixbuf_loader_new(); > gdk_pixbuf_loader_write(loader,data,len,&err); > pixbuf=gdk_pixbuf_loader_get_pixbuf(loader); > gdk_pixbuf_loader_close(loader, NULL); > I guess the order has to be changed. loader=gdk_pixbuf_loader_new(); gdk_pixbuf_loader_write(loader,data,len,&err); gdk_pixbuf_loader_close(loader, NULL); pixbuf=gdk_pixbuf_loader_get_pixbuf(loader); It works for me now. Ill fix it. > I think this is a gdk-pixbuf issue as it is not reproducible consistently. > (It works perfectly for me). > If it had been evolution issue this should have been reproducible consistently. > May be some issue with specific gtk versions, so moving it back to gtk. > > Andrew: It was me who put up that bug link in comment 11, and me only moved > this bug to gdk-pixbuf. What does that mean, i had looked at the solution given > there and it didnt work. We already do whatever was given as a solution for the > bug. > So without knowing the whole picture please dont give statements like in > comment #15.Thanks. >
Created attachment 60040 [details] [review] Committed patch.
Fixed to HEAD.