Closed Bug 841734 Opened 12 years ago Closed 12 years ago

Update libpng to version 1.6.6

Categories

(Core :: Graphics: ImageLib, enhancement)

Product:
Core
Component:
Graphics: ImageLib
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla27

People

(Reporter: glennrp+bmo, Assigned: glennrp+bmo)

References

(Blocks 1 open bug,
URL
)

Details

Attachments

(2 files, 25 obsolete files)

Fixed tab loading animated PNG icon (linux/gnomestripe theme)
11.90 KB, image/png
Details
v25 update-libpng-to-1.6.6
1.26 MB, patch
jrmuizel
: review+
Details | Diff | Splinter Review
Libpng-1.6.0 was released on February 14, 2013. We should upgrade from version 1.5.14 but it's not urgent. Taking bug.
URL: libpng.sourceforge.net
Depends on: 832487
I recommend we let libpng16 bake for a little while. Version 1.6.1 will be out within a few weeks and will have better ARM support and better handling of memory alignment.
Summary: Update libpng to version 1.6.0 → Update libpng to version 1.6.1
The apng patch is going to require a major rewrite before it can be applied successfully to libpng-1.6.x due to a refactoring of pngpread.c, pngread.c, and pngrutil.c. I recommend updating to libpng-1.5.15 first (this will give us the improved ARM support mentioned above).
Depends on: 858578
We (PNG group) have discovered that the improved memory managment in libpng-1.6.x is causing a number of images to be rejected (rightfully so because the "CMF" field in the zlib datastream is incorrect). About 300 of a 140,000 image collection are buggy, and were readable by libpng-1.5.15 and earlier. The PNG group is going to have to ponder this situation for a while, so mozilla might want to wait until 1.6.2 (but go ahead with 1.5.15 now). We haven't identified the application or applications (probably some optimizing post-processor) that has been creating these images. We see them as old as 2004.
More importantly, this icon is broken: chrome://browser/skin/tabbrowser/loading.png I've found one buggy icon in firefox UI, but there could be more, I obviously didn't look for them on purpose.
Changed bug title. Libpng-1.6.2 will be out fairly soon to fix a couple of bugs (not directly affecting mozilla). GIMP built with libpng-1.6.0 or -1.6.1 is generating some unreadable PNG files due to wrong chunk length written in an uncompressed iTXt chunk.
Summary: Update libpng to version 1.6.1 → Update libpng to version 1.6.2
http://sourceforge.net/projects/libpng/files/libpng16/1.6.2/ Libpng 1.6.2 has been released. Has the issues in comment 2 and 3 been solved and is it safe to upgrade or do we wait for 1.6.3 or later versions?
Neither issue has been resolved. We are testing the ARM support in version 1.6.3beta01 and, shortly, in version 1.5.16beta01. That issue has to do with libpng's "configure" script, though, which we don't use with the bundled libpng. Libpng-1.6.2 also continues to reject files with the bad CMF bytes. We still haven't found the application that is generating them.
Updated bug title to call for libpng-1.6.3 which will be out soon and has revised the ARM/NEON support.
Summary: Update libpng to version 1.6.2 → Update libpng to version 1.6.3
(In reply to Glenn Randers-Pehrson from comment #7) > Libpng-1.6.2 also continues to reject files with the bad CMF bytes. > We still haven't found the application that is generating them. According to the pngcheck website¹, there was some "minor zlib-header breakage caused by libpng 1.2.6"; that could be what's generated these invalid PNG images. Any chance of libpng 1.6.3 (or a later version) having a workaround for files that currently fail to load with "IDAT: invalid distance too far back"? We have about 34 packages in Arch Linux that contain invalid PNGs in their source files²³; not a lot, so it's easily fixable. It's a bit hard, however, to make sure no new invalid PNGs sneak in. Thanks. ¹ http://www.libpng.org/pub/png/apps/pngcheck.html ² https://dev.archlinux.org/~foutrelis/invalid-pngs-report/invalid-pngs-packages.txt ³ https://dev.archlinux.org/~foutrelis/invalid-pngs-report/invalid-pngs-community.txt
(In reply to Evangelos Foutras from comment #9) > (In reply to Glenn Randers-Pehrson from comment #7) > Any chance of libpng 1.6.3 (or a later version) having a workaround for > files that currently fail to load with "IDAT: invalid distance too far > back"? Perhaps. I've checked in a workaround to libpng-1.6.3beta04 (only in the GIT repo right now, libpng16 branch), for evaluation by the PNG group. You are welcome to give it a whirl. It is more memory-efficient than libpng15 for many small files that have set their CMF bytes too large, as well as taking care of those with CMF too small.
(In reply to Glenn Randers-Pehrson from comment #10) > (In reply to Evangelos Foutras from comment #9) > > (In reply to Glenn Randers-Pehrson from comment #7) > > > Any chance of libpng 1.6.3 (or a later version) having a workaround for > > files that currently fail to load with "IDAT: invalid distance too far > > back"? > > Perhaps. I've checked in a workaround to libpng-1.6.3beta04 (only in the > GIT repo right now, libpng16 branch), for evaluation by the PNG group. You > are welcome to give it a whirl. It is more memory-efficient than libpng15 > for many small files that have set their CMF bytes too large, as well as > taking care of those with CMF too small. Awesome, thanks; I no longer get "IDAT: invalid distance too far back" errors on the ~300 images that had this issue before. Also worth noting is that Firefox's tab loading icon¹ is fixed as well. (It no longer flickers.) ¹ chrome://browser/skin/tabbrowser/loading.png
(In reply to Glenn Randers-Pehrson from comment #10) > (In reply to Evangelos Foutras from comment #9) > > (In reply to Glenn Randers-Pehrson from comment #7) > > > Any chance of libpng 1.6.3 (or a later version) having a workaround for > > files that currently fail to load with "IDAT: invalid distance too far > > back"? > > Perhaps. I've checked in a workaround to libpng-1.6.3beta04 (only in the > GIT repo right now, libpng16 branch), for evaluation by the PNG group. You > are welcome to give it a whirl. It is more memory-efficient than libpng15 > for many small files that have set their CMF bytes too large, as well as > taking care of those with CMF too small. Sorry to bother you again. Will the workaround not make it into the final 1.6.3 release? (Looks like it has already been removed.)
Look at libpng-1.6.3beta05. The default behavior is to error-out on too-far-back, but this can be overridden via a call that makes libpng revert to the libpng15 behavior. And this will work for both the embedded libpng16 or system libpng16. It will be two weeks or more before libpng-1.6.3 is out.
Maybe it would be better to have libpng15 behavior as the default for libpng16.
There is a big memory penalty for using libpng15 behavior instead of libpng16. For every image we request a 32-kbyte sliding window when for small icons much less is required. Using the libpng16 is a problem because of the smattering of images with bad CMF bytes, from a so far unknown source. I'd like to see an about:config pngMode byte that a user could use to override the default. e.g., pngMode==0, libpng default. pngmode==1, lenient but memory-inefficient. pngmode==2, strict and memory-efficient. Other modes (3-255) reserved for now. If we don't bite the bullet now we'll have the same discussion when upgrading to libpng17, 18, 20, 50. The problem is with the override, libpng doesn't give any warning (because it cannot detect them) about bad CMF bytes, so whatever application is churning them out will continue to do so.
I see libpng 1.5.16 has reached RC status and will be released soon, I think a new bug should be opened and Firefox updated to 1.5.16 when released since the various issues with 1.6.x hasn't been resolved yet. Do you agree with this assessment, Glenn?
(In reply to NVD from comment #17) > I see libpng 1.5.16 has reached RC status and will be released soon, I think > a new bug should be opened and Firefox updated to 1.5.16 when released since > the various issues with 1.6.x hasn't been resolved yet. Do you agree with > this assessment, Glenn? Yes, I'll take care of that.
Depends on: 873001
Glenn, I see that libpng 1.6.3 was released last week. Does it resolve all the issues mentioned here or do we need to wait for libpng 1.6.4 or later?
I think so, but I'm waiting to see what happens with the v20 patch in bug #832390 (ARM support with libpng-1.5.17).
Depends on: 832390
No longer depends on: 832487, 858578, 873001
Please submit to the Try server
Flags: needinfo?(ryanvm)
https://tbpl.mozilla.org/?tree=Try&rev=58c97a6aec91 I really need to setup my Bugzilla whines better. Very sorry for the delay on this.
Flags: needinfo?(ryanvm)
Remove #include pnglibconf.h (not used in mozilla's embedded libpng).
Attachment #788571 - Attachment is obsolete: true
Flags: needinfo?(ryanvm)
Define PNG_GAMMA_SUPPORTED in mozpngconf.h; relocate the include of mozpngconf.h
Attachment #790604 - Attachment is obsolete: true
Flags: needinfo?(ryanvm)
Added defines for PNG_COLORSPACE_SUPPORTED and PNG_IDAT_READ_SIZE (new macros needed for building libpng-1.6)
Attachment #790625 - Attachment is obsolete: true
Flags: needinfo?(ryanvm)
Can you please make sure the patch builds locally before attaching and requesting more Try pushes?
Added several more needed #defines to mozpngconf.h The v04 patch builds OK on Ubuntu 12.04LTS but not tested on any ARM platform.
Attachment #790761 - Attachment is obsolete: true
Flags: needinfo?(ryanvm)
Sorry, I uploaded the wrong patch: v04 was actually another copy of v03. Let's try again, calling it v05 this time.
Attachment #791048 - Attachment is obsolete: true
Flags: needinfo?(ryanvm)
Changed #define PNG_HAVE_ARM_NEON to #define MOZ_PNG_HAVE_ARM_NEON in arm/filter_neon.S. The latter is what is defined in configure.in and passed to the .c sources via moz.build.
Attachment #791130 - Attachment is obsolete: true
You might want to update those to 1.6.3 as well: CHANGES libpng-manual.txt README
Updated CHANGES, libpng-manual.txt, LICENSE, and README to version 1.6.3
Attachment #791555 - Attachment is obsolete: true
https://tbpl.mozilla.org/?tree=Try&rev=2e4d0ef79eb7 Note for the next round that there was a conflict in media/libpng/Makefile.in that needed resolving.
Flags: needinfo?(ryanvm)
Merged Makefile.in Added UNKNOWN support, required with libpng-1.6.3 to build B2G Added BENIGN_ERROR support, required to pass libpng-1.6.3 ref tests
Attachment #791873 - Attachment is obsolete: true
Flags: needinfo?(ryanvm)
This one included hunks for Makefile.in.rej and moz.build.rej, which hg didn't care for. https://tbpl.mozilla.org/?tree=Try&rev=c067b569fea3
Flags: needinfo?(ryanvm)
Thanks. I think the rejections were harmless, but the B2G builds have failed again.
PNG_SET_UNKNOWN_SUPPORTED should have been PNG_SET_UNKNOWN_CHUNKS_SUPPORTED in mozpngconf.h; this error causes B2G builds to fail. Testing new patch locally now.
libpng-1.6.3 introduces a small performance hit on all platforms. The fix is trivial and is in libpng-1.6.4beta01 (fix is to not initialize the row filter functions when all of the rows in the PNG have filter-type NONE, which is frequently the case). I don't know when 1.6.4 will be out; should I go ahead and apply the fix now to mozilla's libpng-1.6.3 patch now?
(In reply to Glenn Randers-Pehrson from comment #41) > libpng-1.6.3 introduces a small performance hit on all platforms Actually it was introduced in libpng-1.5.7, so maybe it would be better to post a separate bug about it.
Fixed B2G builds
Attachment #794318 - Attachment is obsolete: true
Flags: needinfo?(ryanvm)
Updated date and version number in MOZCHANGES
Attachment #794939 - Attachment is obsolete: true
Blocks: 462796
Blocks: 655693
The v10 patch got further but still failed to build B2G because of a missing "#define PNG_READ_UNKNOWN_CHUNKS_SUPPORTED" in the GONK section of mozpngconf.h Please submit to try, and kill whatever is left of the v10 trials.
Attachment #795044 - Attachment is obsolete: true
Flags: needinfo?(ryanvm)
Added another define (#define PNG_STORE_UNKNOWN_CHUNKS_SUPPORTED) to the GONK section of mozpngconf.h, needed to build B2G with libpng-1.6.3
Attachment #795061 - Attachment is obsolete: true
Flags: needinfo?(ryanvm)
v12 appears to need to be resubmitted due to lost connection during the bugzilla maintenance period.
Flags: needinfo?(ryanvm)
I've retriggered the build on the same push.
Flags: needinfo?(ryanvm)
The v12 patch failed to build on B2G with the message "pngrutil.c:3059:10: error: #error no method to support READ_UNKNOWN_CHUNKS". Looks like we need at least one more define, "#define PNG_SAVE_UNKNOWN_CHUNKS_SUPPORTED" in mozpngconf.h, for GONK support (we need the full unknown chunk support in BootAnimation.cpp in order to ignore the tRNS chunk under some conditions). Perhaps there is a better way but that is for another bug.
Attachment #795084 - Attachment is obsolete: true
Flags: needinfo?(ryanvm)
Comment on attachment 748550 [details] Fixed tab loading animated PNG icon (linux/gnomestripe theme) Marking obsolete. This image has been replaced with a newer one in the mozilla-central repository. See browser/themes/linux/tabbrowser/loading.png which is dated June 29, 2013.
Attachment #748550 - Attachment is obsolete: true
(In reply to Glenn Randers-Pehrson from comment #53) > Comment on attachment 748550 [details] > Fixed tab loading animated PNG icon (linux/gnomestripe theme) > > Marking obsolete. This image has been replaced with a newer one in the > mozilla-central repository. See browser/themes/linux/tabbrowser/loading.png > which is dated June 29, 2013. Which branch would that be in? In the default branch this icon hasn't been touched since the theme renaming: http://hg.mozilla.org/mozilla-central/log/default/browser/themes/linux/tabbrowser/loading.png
Test for B2G earlier in configure.in. v13 gave this: in function MOZ_PNG_init_filt_func_neon:../../../gecko/media/libpng/arm/arm_init.c:41: error: undefined reference to 'android_getCpuFamily' It is because of checking MOZ_BUILD_APP before it is defined in configure.in
Attachment #795113 - Attachment is obsolete: true
Flags: needinfo?(ryanvm)
Comment on attachment 748550 [details] Fixed tab loading animated PNG icon (linux/gnomestripe theme) My mistake. I was looking at the June 29 date which is probably when I cloned the hg repository. Not obsolete (but it probably won't get any attention sitting here in this "update libpng" bug).
Attachment #748550 - Attachment is obsolete: false
FYI, this had a conflict in nsPNGDecoder.cpp. https://tbpl.mozilla.org/?tree=Try&rev=692d00758e2d
Flags: needinfo?(ryanvm)
Also, somehow I dropped the new png.c from the v14 patch after my local testing, resulting in this, due to mis-matched png.h and png.c: png.c:17: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Your_png_h_is_not_version_1_5_17'
Restored png.c patch, fixed nsPNGDecoder.cpp conflict.
Attachment #795118 - Attachment is obsolete: true
Flags: needinfo?(ryanvm)
Testing for a "b2g" build didn't work. I think it would be better anyhow to do a test compile to determine whether or not $(ANDROID_NDK)/sources/android/cpufeatures/cpu-features.h is present.
In configure, check for presence of the cpufeatures directory instead of MOZ_BUILD_APP="b2g" when deciding if it's possible to do a runtime check for ARM_NEON capability.
Attachment #795448 - Attachment is obsolete: true
Flags: needinfo?(ryanvm)
unable to find 'image/decoders/nsPfixed' for patching 1 out of 1 hunks FAILED -- saving rejects to file image/decoders/nsPfixed.rej
Flags: needinfo?(ryanvm)
Removed stray "nsPfixed" hunk from patch.
Attachment #795828 - Attachment is obsolete: true
Flags: needinfo?(ryanvm)
The v17 patch has the same problem as v14: arm_init.c:41: error: undefined reference to 'android_getCpuFamily'
Dependence of building cpufeatures upon MOZ_WEBRTC in libpng/Makefile.in appears to be a mistake. Removed it.
Attachment #796011 - Attachment is obsolete: true
Flags: needinfo?(ryanvm)
v18 patch made some progress, but the include of rules.mk was in the wrong place in libpng/Makefile.in.
Attachment #796082 - Attachment is obsolete: true
Flags: needinfo?(ryanvm)
Previously, the loader complained that the cpufeatures functions were undefined. The v19 patch fixes that, abut now the log has a complaint that they are multiply defined. At this point the best approach appears to be to disable the run-time checking for NEON support. We could still leave it in as a configuration option with default being "nocheck".
Changed default configuration of PNG ARM NEON support to "no" (can be configured to "check" or "nocheck" via "--enable-png-arm-neon-support=[check|nocheck]").
Attachment #796136 - Attachment is obsolete: true
Flags: needinfo?(ryanvm)
v20 was green (not surprising because ARM_NEON stuff is disabled by default). v21 restores the #ifndef MOZ_WEBRTC line that was removed from v18 through v20. Please run try on all platforms.
Attachment #796386 - Attachment is obsolete: true
Flags: needinfo?(ryanvm)
With the v21 patch, builds are green on 29 of the 30 platforms. There's no indication that the one failure had anything to do with the patch. Two of the reftests with B2G Emu Opt failed. One was a GIF test, and I can't tell from the log whether the other has anything to do with this patch.
Attachment #796810 - Flags: review?(jmuizelaar)
Comment on attachment 796810 [details] [diff] [review] v21 Update libpng to version 1.6.3 Agreed, all the failures in that push are known and accounted for. LGTM!
Attachment #796810 - Flags: feedback+
Recall the discussion in the first 16 comments or so, that libpng-1.6.3 will reject PNG files that have the "too-far-back" zlib error. This includes http://hg.mozilla.org/mozilla-central/log/default/browser/themes/linux/tabbrowser/loading.png (fixed version attached to this bug) and perhaps others.
(In reply to Evangelos Foutras from comment #55) > (In reply to Glenn Randers-Pehrson from comment #53) > > Comment on attachment 748550 [details] > > Fixed tab loading animated PNG icon (linux/gnomestripe theme) > > > > Marking obsolete. This image has been replaced with a newer one in the > > mozilla-central repository. See browser/themes/linux/tabbrowser/loading.png > > which is dated June 29, 2013. > > Which branch would that be in? In the default branch this icon hasn't been > touched since the theme renaming: > > http://hg.mozilla.org/mozilla-central/log/default/browser/themes/linux/ > tabbrowser/loading.png That animation displays OK with the v21 patched Firefox. "pngfix" (from the libpng-1.6.3 distribution) reports nothing wrong with the file. Same with "pngcheck".
Sounds to me like we need a bug for finding and fixing any broken PNGs in the tree before this can land. Of course, fixing the ones in the tree does nothing for any broken ones on the web...
I only found two "too-far-back" files in last night's mozilla-central: glenn.rp> pngfix -o *.png | grep -v OK | grep -v OPT iCCP TFB default 10 11 995 1960 browser:extensions:pdfjs:icon64.png iCCP TFB default 10 11 995 1960 browser:extensions:pdfjs:icon.png Note that the "too-far-back" error occurs in the compressed iCCP chunk in both files. There are 2464 (out of 3100) that have too large a windowbits value but that's only a performance (requesting too much memory) issue that won't cause the files to be rejected.
Comment on attachment 796810 [details] [diff] [review] v21 Update libpng to version 1.6.3 Review of attachment 796810 [details] [diff] [review]: ----------------------------------------------------------------- So I'm concerned about rejecting images that we previously accepted. Are these images rejected by any other browsers?
I don't know of another browser that uses libpng16. There are a number of non-browser applications that now reject them. Firefox, when using the "system" libpng16, rejects them. It's a fairly simple modification to the patch to make it act like libpng15 and accept them (without issuing a warning), both via the bundled and "system" libpng16.
(In reply to Glenn Randers-Pehrson from comment #82) > There are 2464 (out of 3100) that have too large a windowbits value > but that's only a performance (requesting too much memory) issue > that won't cause the files to be rejected. Is it possible to fix these images?
PS see comment #15. I'll go ahead and produce a patch v22 that is lenient but memory-inefficient. By the way, v21-patched Firefox does not reject either of the two files mentioned in comment #82 because the error is in the iCCP chunk not in the IDAT chunk. The iCCP chunk, not the entire file, gets rejected.
(In reply to Marco Castelluccio [:marco] from comment #85) > Is it possible to fix these images? "pngfix" from the libpng16 distribution will fix both the ones with too small and those with too large windowBits in the zlib header. The "pngzop" script (from pmt.sf.net) can fix them, too, while optimizing the compression better than pngcrush as well.
While testing some PNG files that contain the "too-far-back" error I found that the v21-patched Firefox does not reject them. I had forgotten about this important change from libpng-1.6.2 to 1.6.3: Version 1.6.3beta05 [May 9, 2013] Calculate our own zlib windowBits when decoding rather than trusting the CMF bytes in the PNG datastream. So the "v21" patch is already "lenient" but it does not suffer from the memory inefficiency of always using a 32-kbyte zlib window. There are a few files where it might use a too-large window but in most cases it will use the right size. I won't be making the "v22" patch I mentioned in comment #86.
(In reply to Glenn Randers-Pehrson from comment #88) > While testing some PNG files that contain the "too-far-back" error I found > that the v21-patched Firefox does not reject them. I had forgotten about > this important change from libpng-1.6.2 to 1.6.3: > > Version 1.6.3beta05 [May 9, 2013] > Calculate our own zlib windowBits when decoding rather than trusting the > CMF bytes in the PNG datastream. > > So the "v21" patch is already "lenient" but it does not suffer from the > memory inefficiency of always using a 32-kbyte zlib window. There are a few > files where it might use a too-large window but in most cases it will use > the right size. I won't be making the "v22" patch I mentioned in comment > #86. Just to be clear. Firefox with the v21 patch will decode every png image that the current version decodes?
(In reply to Jeff Muizelaar [:jrmuizel] from comment #89) > Just to be clear. Firefox with the v21 patch will decode every png image > that the current version decodes? Yes, I believe so.
Blocks: 832390
No longer depends on: 832390
Attachment #796810 - Flags: review?(jmuizelaar) → review+
Keywords: checkin-needed
This doesn't apply cleanly anymore due to some recent Makefile changes. Also, I think you should probably request review from a build peer for the Makefile change because it's somewhat non-trivial. Maybe glandium or gps.
Keywords: checkin-needed
There's upstream bit-rot as well. libpng-1.6.4 will be out in several days so I'll incorporate that upgrade in the next patch. This will give us a footprint reduction of around 1.5kb and some (probably negligible) speed optimization. I'll abandon the Makefile.in and configure.in changes for now and just use what's already in the repo, and revisit updating those in bug #832390 after libpng-1.6.4 is checked in.
Summary: Update libpng to version 1.6.3 → Update libpng to version 1.6.5
Attached patch v22 update-libpng-to-1.6.5 (obsolete) — — Splinter Review
libpng-1.6.5 has been released. Here's the updated patch. It does not change Makefile.in or moz.build and does not enable ARM.
Attachment #796810 - Attachment is obsolete: true
Flags: needinfo?(ryanvm)
Attached patch v23 update-libpng-to-1.6.6 (obsolete) — — Splinter Review
v23 updates libpng to version 1.6.6
Attachment #804930 - Attachment is obsolete: true
Summary: Update libpng to version 1.6.5 → Update libpng to version 1.6.6
Comment on attachment 805773 [details] [diff] [review] v23 update-libpng-to-1.6.6 Marking v23 obsolete; it failed local build
Attachment #805773 - Attachment is obsolete: true
Flags: needinfo?(ryanvm)
Attached patch v24 update-libpng-to-1.6.6 (obsolete) — — Splinter Review
The #include mozpngconf.h line was missing from pngpriv.h; fixed in patch v24. This builds OK on Ubuntu.
Flags: needinfo?(ryanvm)
Revised UNKNOWN_CHUNKS defines in mozpngconf.h to achieve a small reduction in footprint of b2b builds.
Attachment #805801 - Attachment is obsolete: true
The v25 try is all green except for several tests. One is an xpshell test on Windows XP opt which may or may not be related, and the others are a reftest on Windows XP debug </layout/reftests/bugs/163504-1b.html> (or -1a.html) in which several colors are off by 1 or 2 levels in 5 pixels: glenn.rp> diff reference.txt test.txt 37620c37620 < 18,47: (186,125, 4,255) #BA7D04 srgba(186,125,4,1) --- > 18,47: (187,125, 4,255) #BB7D04 srgba(187,125,4,1) 38420c38420 < 18,48: (146, 98, 4,255) #926204 srgba(146,98,4,1) --- > 18,48: (148, 99, 4,255) #946304 srgba(148,99,4,1) 39220c39220 < 18,49: (127, 85, 4,255) #7F5504 srgba(127,85,4,1) --- > 18,49: (129, 86, 4,255) #815604 srgba(129,86,4,1) 40020c40020 < 18,50: ( 98, 66, 4,255) #624204 srgba(98,66,4,1) --- > 18,50: ( 99, 67, 4,255) #634304 srgba(99,67,4,1) 40820c40820 < 18,51: ( 41, 27, 4,255) #291B04 srgba(41,27,4,1) --- > 18,51: ( 42, 28, 4,255) #2A1C04 srgba(42,28,4,1) Neither the test image nor the reference image contains any color management chunks (sRGB, gAMA, or iCCP). The test case has to do with resizing (which I believe occurs outside of libpng).
Yes, those failures are known intermittents.
Comment on attachment 808229 [details] [diff] [review] v25 update-libpng-to-1.6.6 The v25 patch should be ready to go now. r? Not asking for review of Makefile.in or moz.build as suggested previously because they aren't changed by v25.
Attachment #808229 - Flags: review?(jmuizelaar)
https://hg.mozilla.org/integration/mozilla-inbound/rev/8b84e9b8e24d Not seeing it here yet, but I did get an IRC r+ to land.
Attachment #808229 - Flags: review?(jmuizelaar) → review+
https://hg.mozilla.org/mozilla-central/rev/8b84e9b8e24d
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla27
Blocks: 938740
See Also: → 945912
See Also: 945912 →
Depends on: 974825
I find that my chrome://browser/skin/tabbrowser/loading.png is not animated now. My firefox is compiled with system libpng 1.6.10 with APNG patch under linux. Is this problem expected?
(In reply to broken.zhou from comment #104) > I find that my chrome://browser/skin/tabbrowser/loading.png is not animated > now. > > My firefox is compiled with system libpng 1.6.10 with APNG patch under > linux. Is this problem expected? I attached a working image in comment 16 but a new bug report is probably needed (see comment 57). Unfortunately, I haven't followed up by filing a new bug...
(In reply to broken.zhou from comment #104) > I find that my chrome://browser/skin/tabbrowser/loading.png is not animated > now. > > My firefox is compiled with system libpng 1.6.10 with APNG patch under > linux. Is this problem expected? This is not a problem. loading.png is now animated using CSS. See bug 759252.
(In reply to Dão Gottwald [:dao] from comment #106) > This is not a problem. loading.png is now animated using CSS. See bug 759252. So do we just pretend it's ok till 32 is released?
(In reply to Michael from comment #107) > (In reply to Dão Gottwald [:dao] from comment #106) > > This is not a problem. loading.png is now animated using CSS. See bug 759252. > > So do we just pretend it's ok till 32 is released? Sounds good to me. I'm just glad I can finally drop my "fixed" loading icon from the Arch Linux Firefox package. :) @Dão: Thanks for the information!
So it takes 5 releases to fix a throbber. :)
(In reply to Michael from comment #107) > (In reply to Dão Gottwald [:dao] from comment #106) > > This is not a problem. loading.png is now animated using CSS. See bug 759252. > > So do we just pretend it's ok till 32 is released? I'm not sure what you mean. Comment 104 doesn't mention any particular version, so I expected it to refer to a recent mozilla-central build where chrome://browser/skin/tabbrowser/loading.png is not supposed to be animated. I'm also not sure why this discussion is taking place in this bug.
Since 759252 is marked as won't fix, should this problem be treated again? Anyway, I filed a new bug report for this: https://bugzilla.mozilla.org/show_bug.cgi?id=1201766 since I am still affected by this problem on gentoo.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: