Install libpng 1.6 and firefox 20.0.1 Open new tab and go to: chrome://browser/skin/tabbrowser/loading.png I've found one buggy icon, but there could be more. Here is discussion in upstream bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=841734 I suggest to make firefox depend on libpng 1.5 just for now. It seems to work good, but user interface is broken, due to this file. Maybe we can fix broken icon just by open and resave, but I think it is something upstream should do. Reproducible: Always
One icon being broken is IMHO not a reason to pin www-client/firefox to libpng-1.5.
Quick user-level fix for this issue. .tab-throbber[progress] { list-style-image: url("chrome://global/skin/icons/loading_16.png")!important; } in userChrome.css This will replace broken icon with good one. As far as I know, we can patch mozilla-release/xulrunner/app/profile/chrome/userChrome-example.css but I don't completely understand how firefox make default userChrome.css.
(In reply to comment #1) > One icon being broken is IMHO not a reason to pin www-client/firefox to > libpng-1.5. Its hardly one graphic that's broken. Its much more if you read the underlying bug. By no means is it a large percentage of images but the total is greater than 1. What's more troubling is that when you save a file with GIMP when using libpng 1.6, that GIMP won't create a valid PNG per the upstream bug.
(In reply to comment #3) > (In reply to comment #1) > > One icon being broken is IMHO not a reason to pin www-client/firefox to > > libpng-1.5. > > Its hardly one graphic that's broken. Its much more if you read the > underlying bug. By no means is it a large percentage of images but the total > is greater than 1. What's more troubling is that when you save a file with > GIMP when using libpng 1.6, that GIMP won't create a valid PNG per the > upstream bug. GIMP is not broken in Gentoo because it was me who told upstream about the bug, then he fixed it based on the provided information and the fixes are in Portage as 1.6.1-r1 already. So lets not mix that up in this bug. I agree with Comment #1 in sense that this isn't worth the trouble forced downgrade would cause to users. I'm using Firefox quite happily here with libpng 1.6 and if it weren't for this report, I wouldn't have even known there are issues with the combination...
(In reply to comment #4) > I'm using Firefox quite happily here with > libpng 1.6 and if it weren't for this report, I wouldn't have even known > there are issues with the combination... I think I didn't mention it, but broken icon is the the one shown on every tab while it loading content, in default skin. But I agree, it isn't worth trouble downgrading libpng.
*** Bug 467504 has been marked as a duplicate of this bug. ***
Problem still exists with version 1.6.2. Upstream is waiting for libpng-1.6.3.
Judging by mozilla bugzilla bug is fixed in libpng 1.6.3beta04.
Created attachment 347700 [details] Patch for 1.6.2 based on upstream git This patch, based on upstream git commit 127b08a265f99ce517ea31ec7988a91fc17da4d9, applied to libpng-1.6.2 and resolved this issue for me. I can only recommend using it if you do not want to wait for 1.6.3, only because I have not performed extensive testing on it and don't have enough knowledge to say that it's acceptable for general use. But it is based on an upstream commit (only cosmetic changes).
https://bugzilla.mozilla.org/attachment.cgi?id=748550 There is fixed icon in upstream bugzilla. Could we place it in ${FILESDIR} and replace build-time? I did it in local overlay: cp ${FILESDIR}/loading.png ${WORKDIR}/mozilla-release/browser/themes/gnomestripe/tabbrowser/loading.png
(In reply to comment #10) > https://bugzilla.mozilla.org/attachment.cgi?id=748550 > > There is fixed icon in upstream bugzilla. Could we place it in ${FILESDIR} > and replace build-time? > > I did it in local overlay: > cp ${FILESDIR}/loading.png > ${WORKDIR}/mozilla-release/browser/themes/gnomestripe/tabbrowser/loading.png No we will not, we will wait for libpng-1.6.3 to be released or the patch landed in libpng-1.6.2 bug report. It fixes the icon without needing to mess with icons in firefox.
(In reply to comment #11) > No we will not, we will wait for libpng-1.6.3 to be released or the patch > landed in libpng-1.6.2 bug report. It fixes the icon without needing to mess > with icons in firefox. This isn't how it looks. From what I uderstand, icon was broken, and was rejected rightfully. Patch in libpng is merely workaround, that allow optionally revert to previous, libpng1.5 behaviour. I'm sure it will be fixed in firefox upstream eventually, but I think it could be a while, until upstream switch to libpng1.6. In meantime in gentoo we already have libpng1.6 in ~x86, and default user interface in firefox is broken. I understand it is minor issue, but nonetheless, imagine how annoying it would be to see constant epileptic seizure on every tab.
*** Bug 470176 has been marked as a duplicate of this bug. ***
The patch won't make it to 1.6.3 or any other release. The broken images won't show up in future releases either. See, https://bugzilla.mozilla.org/show_bug.cgi?id=841734#c12 And comments below it. So if the loading.png is broken, it needs to be fixed like suggested in Comment #10 As in, waiting for 1.6.3 won't solve this for mozilla.
Comment on attachment 347700 [details] Patch for 1.6.2 based on upstream git patch upstream reverted and won't go to tree. the default libpng behavior will stay like it is 1.6.0, 1.6.1, 1.6.2 and the images with broken IDAT won't show
1.6.3 is released and won't fix this bug magically for firefox. since it's firefox that is broken, i'll switch this bug to block 468386. note that this won't be a blocker for libpng 1.6.3 stabilization, so please get the broken icons fixed that are shipped with firefox. note that the libpng 1.6.3 comes with binaries to fix the broken images: $ qlist libpng |grep bin.*fix /usr/bin/png-fix-itxt /usr/bin/pngfix
for example, https://bugzilla.mozilla.org/show_bug.cgi?id=841734#c16 should be included in any firefox ebuild that has broken loading icon
This hasn't been a problem for quite a while now.
(In reply to Samuli Suominen from comment #18) > This hasn't been a problem for quite a while now. It still persists for me with firefox-26.0 & libpng-1.6.7.
It's ok. In firefox 27 upstream will switch to libpng 1.6, then they will fix it. But why it's marked 'fixed' now? It's not.
(In reply to Michael from comment #20) > It's ok. In firefox 27 upstream will switch to libpng 1.6, then they will > fix it. > But why it's marked 'fixed' now? It's not. Using 1.6 at Firefox upstream is NOT a prereq for this bug, but using the proper .png files like in Comment #17 is That's enough to make the loading icon stop glitching I'm looking at www-client/firefox-25.0.1 with libpng-1.6.8 without any glitches as we speak
letting the mozilla maintainers close the bug then, but this has been fixed half an year by now
(In reply to Samuli Suominen from comment #21) > (In reply to Michael from comment #20) > > It's ok. In firefox 27 upstream will switch to libpng 1.6, then they will > > fix it. > > But why it's marked 'fixed' now? It's not. > > Using 1.6 at Firefox upstream is NOT a prereq for this bug, but using the > proper .png files like in Comment #17 is > That's enough to make the loading icon stop glitching > I'm looking at www-client/firefox-25.0.1 with libpng-1.6.8 without any > glitches as we speak Then we should fix it in ebuild, like here in https://bugs.gentoo.org/show_bug.cgi?id=465838#c10 do we?
(In reply to Michael from comment #23) > (In reply to Samuli Suominen from comment #21) > > (In reply to Michael from comment #20) > > > It's ok. In firefox 27 upstream will switch to libpng 1.6, then they will > > > fix it. > > > But why it's marked 'fixed' now? It's not. > > > > Using 1.6 at Firefox upstream is NOT a prereq for this bug, but using the > > proper .png files like in Comment #17 is > > That's enough to make the loading icon stop glitching > > I'm looking at www-client/firefox-25.0.1 with libpng-1.6.8 without any > > glitches as we speak > > Then we should fix it in ebuild, like here in > https://bugs.gentoo.org/show_bug.cgi?id=465838#c10 do we? I just rechecked, there is really nothing to do here: $ qlist -CIv firefox libpng media-libs/libpng-1.6.10 www-client/firefox-27.0.1 No glitching icons anymore, the one from Comment #10 is included in the upstream tarball: $ tar xf /usr/portage/distfiles/firefox-27.0.1.source.tar.bz2 -C /tmp/ $ firefox /tmp/mozilla-release/browser/themes/linux/tabbrowser/loading.png Same as in https://bug841734.bugzilla.mozilla.org/attachment.cgi?id=748550
