User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040618 Firefox/0.8.0+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040618 Firefox/0.8.0+ This sample is a simple box image, however, Mozilla does not display the bottom line. Maybe it is because of the reason written in the summary: +---------IDAT---------+---------IDAT---------+ |...data, data, dataend| Zlib's CRC and end | +---------IDAT---------+---------IDAT---------+ Reproducible: Always Steps to Reproduce:
Attachment #151168 - Attachment description: Sample iImage. → Sample image.
15 years ago
Component: Image: GFX → ImageLib
When I use mozilla configured with libmng providing PNG support, the bottom line of the image is shown properly. But if libpng provides PNG support, then I can confirm that the bottom line is missing.
Status: UNCONFIRMED → NEW
Ever confirmed: true
The bug doesn't seem to be in libpng. ImageMagick's "display" and both libpng's contrib/gregbook/rpng-x and rpng2-x display the complete image. Rpng2-x uses the same progressive reading method that mozilla uses.
Instrumenting the png decoder, we're not getting a row callback for the last row.
Right. That would probably be the fault of png_process_IDAT_data() in pngpread.c which happens to be troublesome, hard-to-follow code that has had bugs in the past.
Created attachment 151190 [details] Another sample. The bottom line of this second sample is also not displayed which only the CRC 4 bytes of zlib-compressed-data are in another IDAT chunk. This bug seems to occur when any bytes of zllb's CRC 4 bytes are separated from its data field, not relating to BFINAL.
Summary: The bottom line of PNG not displayed when the end of the image data and the zlib's BFINAL/CRC are in different IDAT chunks. → The bottom line of PNG not displayed when the end of the image data and the zlib's CRC are in different IDAT chunks.
Created attachment 151217 [details] [diff] [review] patch for libpng pngpread (bugzilla 247604) This patch appears to correct the problem. libpng's progressive reading function was incorrectly finding too much data under circumstances where the expected pixel data had all been aquired but there was some remaining zlib data still to be processed.
Assignee: jdunn → glennrp
Status: NEW → ASSIGNED
The patch for libpng's pngpread was applied to libpng version 1.2.6, so upgrading to 1.2.6 will fix this bug. Glenn
Although libpng-1.2.7 has been checked in to trunk, I'm still seeing this bug with Firefox (rv:1.7.3) Gecko/20041027 Firefox/1.0RC1 (amano). I assume another checkin of bug #261922, to aviary, is required.
All testcases WFM on the latest trunk (at least, I see the bottoms of all the boxes), and I think it's safe to say that this isn't going to be fixed on the 1.0.x branch. Maybe a VERIFIED FIXED is in order?
Setting blocking flags to "?" for FF 1.0.8 and Moz 1.7.13. If some authority answers with "-" then we can close this bug as FIXED (and imply wontfix these earlier branches).
Since there seems to be no interest in fixing the 1.7 branch, I'm marking this bug FIXED, and by implication, WONTFIX the 1.7 branch.
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.