Description of problem: (at least some) animated gifs do not work in firefox Version-Release number of selected component (if applicable): firefox-3.6.7-1.fc13.x86_64 How reproducible: open e.g. http://www.fahrradkurier-forum.de/images/smilies/schulter0001.gif (which coincidentally summarizes this bug so far). Actual results: you see only the first frame of the gif, then it is transparent. Expected results: neatly animated gif Additional info: the gif shows fine in eog.
happens as well with firefox-3.6.7-1.fc14.x86_64 (from koji).
maybe this upstream bug is related: https://bugzilla.mozilla.org/show_bug.cgi?id=552986
I did experience this issue in i686 version too. Animated gifs with alpha channel aren't displayed correctly. I tried to turn off all plugins and extensions - and safe-mode too - but nothing corrected that. The non-rpm version of firefox from mozilla's site works fine. After some tweaking I remember I solved it someway - one month ago, more or less - but I don't remember how (...) and now I have this issue again in a brand-new fedora installation. As far as I remember is unrelated with bugzilla.mozilla upstream. This happens in fedora 13 as well as 14 and 15 (rawhide)
I forgot to mention that I use the KDE spin; also, I went through all the " kb.mozillazine.org/Images_or_animations_do_not_load " but with no result.
Experiencing this in F14 (alpha) as well.. firefox-3.6.7-1.fc14.x86_64 -- Built 3.6.8 using the 3.6.7 F14 spec, same results. xulrunner-1.9.2.7-2.fc14.x86_64 -- if it matters. Seemed to happen after the upgrade to F14 from F13, but I can't pin point that as a certainty -- could merely be a coincidence.
FWIW; I also experience this bug on a fresh F14 Alpha x86_64 install with all updates applied. xulrunner-1.9.2.7-2.fc14.x86_64 firefox-3.6.7-1.fc14.x86_64 While xulrunner-1.9.2.7-2.fc13.x86_64 firefox-3.6.7-1.fc13.x86_64 on my F13 x86_64 box does not exhibit the bug
Seeing this problem as well: I upgraded two machines from F13 to F14 recently and at about the same time firefox (and seamonkey) stopped displaying the animated weather/rain radar images on two different German websites that are dedicated to weather reporting: http://niederschlagsradar.de/h.aspx?j=-3&srt=loop1stunde®io=han&c=1 http://www.wetterspiegel.de/de/europa/deutschland/47.html (There is nearly always some rain somewhere in Germany, so if nothing changes it's a sign that there is something wrong; one frame of the animated gif is shown) Version-Release number of selected component (if applicable): firefox-3.6.7-1.fc14.x86_64 How reproducible: always firefox-3.5.12-1.fc12.x86_64 on a F12 machine is able to display the website remotely just fine
(In reply to comment #2) > maybe this upstream bug is related: > https://bugzilla.mozilla.org/show_bug.cgi?id=552986 The two images linked from that bug report work just fine here
you are right. this does work (i don't really know, why i did not check this. the description in the bug is identical...). sorry about it.
Just verified: Problems shows up with firefox-3.6.7-1.fc14.x86_64 xulrunner-1.9.2.7-2.fc14.x86_64 on FC14 but doesn't show with firefox-3.6.7-1.fc13.x86_64 xulrunner-1.9.2.7-2.fc13.x86_64 on a USB-Live-Stick with F13 where I updated only firefox and xulrunner to the latest version. Is there maybe some external library which is the root of this bug? @gecko-maintainers: If there is a external lib involved in displaying gif images could you please tell us which one? Then we might be able to further track this problem down on our own and get it of your bug list ;-)
For what it's worth, pulled Firefox from Rawhide and it seems to have resolved the issue... Not an ideal fix, but I'll live with it for now. :) [jeff@jeff ~]$ rpm -q firefox xulrunner sqlite firefox-4.0-0.2b4.fc15.x86_64 xulrunner-1.9.3.0-0.2b4.fc15.x86_64 sqlite-3.7.0.1-2.fc15.x86_64
If Fedora's compiling firefox with system cairo, it's probably cairo 1.10's fault (see also Gentoo bugreport http://bugs.gentoo.org/show_bug.cgi?id=337813). This is probably caused by the less tolerant nature of cairo 1.10, see snapshot 1.9.10 release notes: 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! Mozilla should've already updated their internal copy of cairo to 1.9/1.10 a few months ago, so probably trunk (or branch 1.9.3) have the needed fixes and it shouldn't be too complicated to port them to 1.9.2, it's just that I can't figure out how to use their obnoxious VCS.
(In reply to comment #12) > If Fedora's compiling firefox with system cairo, it's probably cairo 1.10's > fault [...] Downgraded to cairo-1.8.10-1.fc13.x86_64.rpm on my F14 machine and voila, the animated Gifs that were broken are now displayed properly again by the firefox from F14
F13: works with firefox-3.6.10-1.fc13.x86_64 cairo-1.8.10-1.fc13.x86_64 F14: does not work properly with firefox-3.6.10-1.fc14.x86_64 cairo-1.10.0-1.fc14.x86_64 Rawhide: works with firefox-4.0-0.3b6.fc15.x86_64 cairo-1.10.0-2.fc15.x86_64
*** Bug 637702 has been marked as a duplicate of this bug. ***
Upstream bug seems to be https://bugzilla.mozilla.org/show_bug.cgi?id=597174
*** Bug 641097 has been marked as a duplicate of this bug. ***
Still present in firefox-3.6.11-1.fc14.x86_64 xulrunner-1.9.2.11-1.fc14.x86_64
This is most likely related to the image loader loading data into a Cairo image surface but forgetting to call cairo_surface_mark_dirty() after and/or cairo_surface_flush() before the modifications. As Cairo 1.10 is much stricter about enforcing these requirement than 1.8 was, it might indeed be that the bug does only show up in Cairo 1.10. So I'm reassigning it back to Firefox.
according to comment 14, i guess that the changes should be backported from gecko-2 branch to current gecko-1.9.2 and gecko-1.9.1 branches
For those of you who think that "being able to render images found on the web" is an important feature you can't live without, the Cairo 1.8.10 RPMs from F13 appear to work just fine in F14.
What's quicker, making the fixes in Gecko so it renders correctly with the more strict Cairo or creating a cairo18 package coexisting with the current Cairo and linking Firefox to it instead?
Yes, I can reproduce this with firefox-3.6.12-1.fc14.x86_64 and cairo-1.10.0-2.fc14.x86_64.
I see the same problem in seamonkey-2.0.10-1.fc14.i686. First thing I noted after F14 upgrade was that in SeaMonkey, activity indicators on tabs (normally they are rotating arrows when page is loading) are just blinking erratically. Turns out no animated gifs work on pages either. Should I open another bug against SM or does it belong to Cairo?
Re: comments #13, #21 The Cairo RPM from F13 fixes the issue with the firefox, but it makes the evince PDF viewer unable to open a PDF document.
Please do not suggest such solutions as downgrading to F13 rpm. FWIW, mozilla is actively working to solve this issue.
*** Bug 651849 has been marked as a duplicate of this bug. ***
I just upgraded from F13 to F14, same problem. F13 was OK, F14 - cairo-1.10.0-2.fc14 , firefox-3.6.12-1.fc14 making troubles.
I think this bug can be safely marked as CLOSED UPSTREAM since mozilla is working on it.
If you mark it closed just because it may someday be fixed, then no one finding the bug before its fixed and searching bugzilla will find this bug anymore.
I agree with Tom Horsley, for a variety of reasons: - Visibility, as he points out; - CLOSED UPSTREAM looks better suited to problems that are already fixed upstream but aren't yet in the distro, maybe because a backport operation is needed; - I don't see THAT much enthusiasm in the Mozilla bugzilla; - There's always the possibility of sidestepping the problem by doing what I say in Comment #22.
Just as a data point, the firefox-3.6.12.tar.bz2 from Mozilla installed to /usr/local does not exhibit the same rendering problems.
That is because Mozilla statically compiles libcairo into the firefox binary. And they use 1.8.x.heavily-patched internally.
(In reply to comment #33) > That is because Mozilla statically compiles libcairo into the firefox binary. > And they use 1.8.x.heavily-patched internally. In my opinion, Fedora should do the same thing until the wrong usage of Cairo is corrected in Firefox code.
Yes, bundling seems to be a good solution in this case, I am voting for it.
(In reply to comment #35) > Yes, bundling seems to be a good solution in this case, I am voting for it. This solution also may work for seamonkey.
I may try the mozilla version when I get back to work. I'm curious if bug 649475 is a similar cairo issue.
I would definitely nominate this bug for a CommonBugs page of F14...
Added to F-14 Common Bugs : https://fedoraproject.org/wiki/Common_F14_bugs#Some_animated_gifs_are_not_properly_displayed_in_firefox_and_seamonkey
Bug 649475 does appear to be a different instance of a cairo problem messing with firefox. The text shredding when scrolling out from under an overlapping window does not happen with the mozilla binary.
Mozilla mark it as resolved, one of the linked bug. Would it be addressed really to cairo maintainer?
I tried to rebuild the Fedora 14 firefox SRPM adding the patch in the Mozilla bug to the spec, it seemed to build OK but I got the following error when trying to update the resulting rpm: $ sudo rpm -Fvh /home/jcastro/rpmbuild/RPMS/i686/firefox-3.6.12-2.fc14.i686.rpm Preparing... ########################################### [100%] 1:firefox ########################################### [100%] error: unpacking of archive failed on file /usr/lib/firefox-3.6/firefox;4cf9b483: cpio: Digest mismatch I'm going to attach the patch and my changed spec.
Created attachment 464701 [details] Attempt to add patch to Firefox RPM This includes my spec attempt and the patch file (identical to the one found in the Mozilla bugzilla). Builds OK, installing fails.
Oh, great, it seems I've run into bug #437608. I used Hicham Haouari's suggestion (https://bugzilla.redhat.com/show_bug.cgi?id=437608#c24) and it installs now. ...But the GIF problem remains.
(In reply to comment #44) > Oh, great, it seems I've run into bug #437608. I used Hicham Haouari's > suggestion (https://bugzilla.redhat.com/show_bug.cgi?id=437608#c24) and it > installs now. > > ...But the GIF problem remains. You should patch xulrunner
Created attachment 464803 [details] Patch and spec for xulrunner. This seems to fix the bug. Install the xulrunner SRPM, place the patch in ~/rpmbuild/SOURCES, the spec in ~/rpmbuild/SPECS, run rpmbuild -ba ~/rpmbuild/SPECS/xulrunner.spec And you're good to go. Animated GIFs are animated.
Patch does not work to Seamonkey. Bug still persist in it.
@Alexei: yes, Seamonkey doesn't seem to use xulrunner, and its code is different. The patch doesn't apply. Let me see if I can adapt it.
@Juan Carlos: would be very grateful! Thanks!
@Alexei: I'm having some difficulty. I asked for help to the patch author.
Why isn't Fedora doing something to shield their users from this FF bug? Doesn't make sense to make us live with it until its "fixed" upstream. This bug report is nearly 4 MONTHS OLD!!!
The same package (firefox 3.6.13) works fine with cairo 1.8.10 and is broken with cairo 1.10.0. If the regression is caused by cairo (need to check) it would be better to fix the cairo library.
According to previous posts, cairo is fixed in 1.10 compared to 1.8, but FF is using incorrect access to cairo.
the patch in upstream bz seems to fix it, why not use it in Fedora ?
Fedora updated xulrunner and didn't include the patch. Here's an updated xulrunner for you all to test. Sorry, no x86_64 binaries, you'll have to rebuild the SRPM: http://users.vialink.com.br/jcastro/xulrunnerfix I'll try to keep this updated if Fedora keeps putting out xulrunner's with the bug.
"Fedora updated xulrunner and didn't include the patch." It was an urgent security update.
I'm sorry if that came out as female-dog-ish, I tried to state the fact without judging. Anyway, can we hope for that fix to be included? It's visual, and makes things look ugly and broken to the end-user.
We can't include patches for mozilla applications until we get mozilla approval.
I believe when the patch is simply a backport of an upstream fix, it's okay. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
If fedora is so concerned about being exactly like mozilla, then why is the firefox rpm already so different from the mozilla binaries? The mozilla binary ships with its own built in cairo that works as expected. Shouldn't fedora do the same thing if being exactly like mozilla is so important?
Here's a familiar failing animated gif: http://glocktalk.com/forums/images/smilies/anim_rofl2.gif kind of sums up the politics of this bug. Can't believe Fedora ships and then sustains bugs in its system like this. Ubuntu is calling me... (been a Fedora user since FC2 and RH since 7 something).
Bugzilla is a bug tracker, not a discussion forum. Please take the drama somewhere else. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
@Martin Stransky : Any progress on this bug ?
xulrunner-1.9.2.13-3.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/xulrunner-1.9.2.13-3.fc14
xulrunner-1.9.2.13-5.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update xulrunner'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/xulrunner-1.9.2.13-5.fc14
*** Bug 666974 has been marked as a duplicate of this bug. ***
I can confirm that xulrunner-1.9.2.13-5.fc14.x86_64 solves the rendering of GIF:s, tab icons and address bar icon in Firefox.
This new xulrunner did indeed fix the animated gif problem for me as well, but didn't fix the corrupted text when scrolling problem which also seems to be cairo related (bug 649475).
seamonkey-2.0.11-2.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/seamonkey-2.0.11-2.fc14
This does seem to fix firefox, but the same problem of animated gifs not displaying properly in thnderbird, Bug 662179, is not fixed.
This does seem to fix firefox, but the same problem of animated gifs not displaying properly in thunderbird, Bug 662179, is not fixed.
xulrunner-1.9.2.13-5.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
Unfortunately with this update firefox fonts now look terrible. Is there another option other than simply disabling cairo?
@Fewt: try my version at Comment #55 -- although I, being not a very keen aesthetic judge, didn't notice any difference. Could you post screenshots "before" and "after"?
Well, this is interesting. I tried to take the screenshots on another computer and it doesn't have the problem. There are a few others reporting it here though: http://www.infinality.net/forum/viewtopic.php?f=2&t=57 When I get back to the other computer I'll gladly post them.
The reason for this is, that xulrunner is now build with internal mozilla cairo. This version of cairo does not have lcd filtering contrary to linking to system cairo which has it. This a reason for a problem with fonts. Until FF is fixed you may choose - ugly fonts or blinking gifs..
Or we can download the statically linked versions of Firefox and Thunderbird from Mozilla and install them. I did. No ugly fonts and no blinking gifs.
seamonkey-2.0.11-2.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.