Since the update of world when firefox-3.6.9 was installed, some animated gifs (mainly emoticons) are showed with the first frame followed by white frames, downgrading to firefox-3.6.8 don't solve the problem, and the browsers that depends in xulrunner have the same isue.
Steps to Reproduce:
1. Upgrade Firefox to version 3.6.9
2. Use some browser that depends in xulrunner
3. Open the gif in http://img72.imageshack.us/img72/2442/452337sephirotr.gif within the browser.
Flickering image showing the first frame followed by white frames
Show the all the frames of the gif
Firefox's binary package display the gifs correctly. And when I make the compilation by myself (ebuild unpack, configure and make) the resulting binary behaves correctly.
# emerge --info
Portage 22.214.171.124 (default/linux/amd64/10.0, gcc-4.4.4, glibc-2.12.1-r1, 2.6.35-gentoo-r5 x86_64)
System uname: Linux-2.6.35-gentoo-r5-x86_64-AMD_Athlon-tm-_64_X2_Dual_Core_Processor_5000+-with-gentoo-2.0.1
Timestamp of tree: Fri, 17 Sep 2010 12:30:01 +0000
distcc 3.1 x86_64-pc-linux-gnu [disabled]
ccache version 2.4 [enabled]
dev-lang/python: 2.6.5-r3, 3.1.2-r4
sys-devel/autoconf: 2.13, 2.67
sys-devel/automake: 1.4_p6-r1, 1.6.3-r1, 1.8.5-r4, 1.9.6-r3, 1.10.3, 1.11.1
virtual/os-headers: 2.6.35 (sys-kernel/linux-headers)
ACCEPT_LICENSE="* -@EULA LOKI-EULA dlj-1.1 googleearth AdobeFlash-10.1"
CFLAGS="-O2 -pipe -march=athlon64-sse3"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config /var/lib/hsqldb"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-O2 -pipe -march=athlon64-sse3"
FEATURES="assume-digests ccache distlocks fixlafiles fixpackages metadata-transfer news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTDIR_OVERLAY="/usr/local/portage /var/lib/layman/kde-sunset /var/lib/layman/kde"
USE="3dnow 3dnowext X aac alsa amd64 audiofile bash-completion berkdb bzip2 cairo cdr cjk cli consolekit cracklib crypt cxx dbus dri dvd dvdr embedded emerald enca encode expat extras faac fbcon ffmpeg firefox flac flatfile fontconfig fortran fuse gdbm gif gnutls gpm gtk hal iconv icu imagemagic ipv6 jpeg kde lame libnotify lm_sensors lua mad matroska mikmod mime mmx mmxext mng modules mozilla mp3 mp4 mpeg mplayer msn mudflap multilib mysql ncurses nls nptl nptlonly nsplugin ntfs offensive ogg openal opengl openmp pam pcre perl plasma png pppd python qt3support qt4 rar raw readline reflection sdl secure-delete session smp sndfile sql sse sse2 sse3 ssl svg sysfs tcpd tga theora threads tiff truetype unicode vdpau videos vorbis wavpack webkit x264 xcomposite xorg xosd xv xvid zeroconf zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="nvidia nv" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset: CPPFLAGS, CTARGET, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
*** Bug 337933 has been marked as a duplicate of this bug. ***
You will have to be more specific as to which browser, this is not happening with firefox-3.6.9
(In reply to comment #2)
> You will have to be more specific as to which browser, this is not happening
> with firefox-3.6.9
Reading the bug 337933 this issue is caused by x11-libs/cairo-1.10.0-r3. When instaled, all browser depending on xulrunner (eg.: firefox, galeon, icecat and epiphany-2.26.3-r4) show the flickering gifs.
www-client/seamonkey is also affected so I think it's safe to say that any mozilla-based browser is affected by this.
Now the question is wether this is a bug in cairo or mozilla packages...
(In reply to comment #4)
> www-client/seamonkey is also affected so I think it's safe to say that any
> mozilla-based browser is affected by this.
> Now the question is wether this is a bug in cairo or mozilla packages...
This is probably due to changes in cairo behaviour, see snapshot 1.9.10's release notes (http://lists.cairographics.org/archives/cairo/2010-June/020204.html):
The first "quick" snapshot in the run up to the stable release. The
last snapshot was picked up by the bleeding edge distributions and so the
bug reports have to started to roll in. The most frequent of these are the
introduction of rendering errors by applications that modify a surface
without subsequently calling cairo_surface_mark_dirty(). Make sure the
application developers are aware of increased reliance on strict use of the
Cairo API before 1.10 is released!
Chromium for example suffered from a similar issue in June (http://code.google.com/p/chromium/issues/detail?id=47064). This problem has been reported in Fedora/Red Hat bugzilla too, but they didn't track it down to cairo yet (https://bugzilla.redhat.com/show_bug.cgi?id=628331). Can't find nothing relevant in Mozilla Bugzilla.
(In reply to comment #0)
> Firefox's binary package display the gifs correctly. And when I make the
> compilation by myself (ebuild unpack, configure and make) the resulting binary
> behaves correctly.
This is due to the fact that firefox uses internal cairo while gentoo uses system cairo. For not the only solution will be to use -bin if you can not live with it. I will have to rework a large amount of code to backport the fix from trunk which could take a while.
Seamonkey is outta here:
*seamonkey-2.0.8-r1 (20 Sep 2010)
20 Sep 2010; Lars Wendler <firstname.lastname@example.org>
Switching over to bundled cairo lib as seamonkey-2.0.x has issues with
cairo-1.10.0. If you don't like this blame upstream as they don't care
about anything than their damned bundled shit!!!
(In reply to comment #6)
> (In reply to comment #0)
> > Firefox's binary package display the gifs correctly. And when I make the
> > compilation by myself (ebuild unpack, configure and make) the resulting binary
> > behaves correctly.
> This is due to the fact that firefox uses internal cairo while gentoo uses
> system cairo. For not the only solution will be to use -bin if you can not live
> with it. I will have to rework a large amount of code to backport the fix from
> trunk which could take a while.
I opted for mask cairo-1.10.0-r3
I can confirm everything here so far. I've reverted to 1.8.10, but doing so appears to break things like Evince/Poppler's PDF rendering ability, as well as GIMP's ability to compile due to missing symbols in the older Cairo version. Since anything from Cairo ~1.9 isn't in the main tree I'll have to go with firefox-bin until a patch is released. If I can help provide information, please respond with a request.
Also seeing this gif issue on firefox 3.6 Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.2) Gecko/20100212 Gentoo
This also breaks svg/svgz rendering where some vertical lines fail to render.
reverting to x11-libs/cairo-1.8.10 fixed it.
Looks like API breakage or incompatible changes.
Why the hell can't developers avoid these constant problems by respecting backwards compatibility?
3/4 of the effort that goes into OOS seems to be absorbed by this kind of crap and probably an even larger part of the time it takes me to deal with gentoo updates.
Let's make cairo-maintainers aware of the situation...
You should take this up with Gentoo I suppose. Firefox by default builds with
it's own internal cairo that is tested to work with it.
As for the lines, how about attaching a sample and seeing if this commit helps http://cgit.freedesktop.org/cairo/commit/?h=1.10&id=e9bb70d2dee4ef7a54e3971f09a08df30c2b5287
As for gifs, one of the bugs says there's no problem in recent 4.0 betas;
finding anything in those sources is a pain, but some of the entries here http://hg.mozilla.org/releases/mozilla-2.0/log/09565753ce5f/modules/libpr0n/src/imgFrame.cpp look promising, hard to tell though if it's even back-portable,
far less if it's actually relevant.
OK, as for the lines, cairo patch works.
As for the gifs, I managed to narrow it down to an about 4k working patch
It will follow shortly, though I'm still unsure if I didn't get too much or not enough (perhaps even both).
Created attachment 256003 [details, diff]
patch for the gif problem
This (sort of) backported patch makes animated gifs displayed correctly.
I hope I've done it correctly.
(In reply to comment #15)
> Created an attachment (id=256003) [details]
> patch for the gif problem
> This (sort of) backported patch makes animated gifs displayed correctly.
> I hope I've done it correctly.
You would have to run this pass upstream, I do not believe they will take it, problem is 1.9.2 branch uses an older cairo and that is what they want distros to use as they have enhancements and tweaks in their code not found in upstream yet. Please post it upstream and assisgn it for review.
Well, it's sort of is upstream already.
I only took a look at http://hg.mozilla.org/releases/mozilla-2.0/log/09565753ce5f/modules/libpr0n/src/imgFrame.cpp
tried to figure out which of those commits are not yet in 1.9.2 and relevant to this problem, combined them into single patch and it worked.
That's why I'm saying I'm not sure I took enough. However, as I mentioned, it works, so till 2.0 goes stable...
Rafal I have reviewed the patch more closely this morning, I do believe Joe is gonna sign off on it. I have tested locally with stable and test all seems fine, as long as I do not see any crash in next 10 hours will push it to tree. Thanks for your work to backport the fix.
Sorry for the delay it has landed in CVS should hit mirrors shortly.