IMG.complete must return false for images in the Broken state -- eg corrupted or truncated -- however, it returns true instead. HTML5 specifies [1] that IMG.complete must return true if any of the following are true: * The src attribute is omitted. * The src attribute's value is the empty string. * The final task that is queued by the networking task source once the resource has been fetched has been queued, but has not yet been run, and the img element is not in the broken state. * The img element is completely available. Otherwise, the attribute must return false. IMGs with specified src attributes, other than the empty string, that result in "Image corrupt or truncated" console errors, should be regarded as being in the Broken state. As such, IMG.complete should then return false. HOWEVER, while Firefox logs "Image corrupt or truncated" errors, indicating that the image is regarded in the Broken state, Firefox (incorrectly) continues to return IMG.complete as true. Verified behavior is consistently incorrect. Converted a sample image to multiple filetypes: A AAI AI ART AVS B BGR BGRA BMP BMP2 BMP3 BRF C CAL CALS CIN CIP CMYK CMYKA CUR DCX DPX EPDF EPI EPS EPS2 EPS3 EPSF EPSI EPT EPT2 EPT3 EXR FAX FITS FTS G G3 GIF GIF87 GRAY GROUP4 HDR HISTOGRAM HRZ HTM HTML ICB ICO ICON IPL ISOBRL J2C JNG JP2 JPC JPEG JPG K M MAT MATTE MIFF MNG MONO MPC MSVG MTV NULL O OTB PAL PALM PAM PBM PCD PCDS PCL PCT PCX PDB PDF PDFA PFM PGM PICON PICT PJPEG PNG PNG24 PNG32 PNG8 PNM PPM PREVIEW PS PS2 PS3 PSB PSD PTIF R RAS RGB RGBA RGBO SGI SHTML SUN SVG SVGZ TEXT TGA TIFF TXT UBRL UIL UYVY VDA VICAR VID VIFF VST WBMP X XBM XPM XV XWD Y YUV Made three copies of each for an original, a corrupted, and a truncated file. Corrupted files replacing content in the middle of the file with a random string. Truncated files by deleting from random locations in the files. Created a html page with every image from all 3 sets and verified IMG.complete versus the HMTL5 specification, as above. Despite images being very evidently visually corrupted, and despite images being truncated to the point where they could not be decoded, EVERY SINGLE IMG RETURNED IMG.complete as TRUE! Naturally, the expectation was that IMG.complete would be: * true for the original set, IFF the format was supported by firefox * FALSE for the original set, IFF the format was not supported by firefox * true for the corrupted set, IFF the corruption happened to result in a valid image * FALSE for the corrupted set, IFF the corruption resulted in an invalid image * true for the truncated set, IFF the random deletions happened to result in a valid image * FALSE for the truncated set, IFF the deletions resulted in an invalid image [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#dom-img-complete

I think we have an existing bug on this. I'm also not sure that the DOM has the information to do this right given current imagelib APIs. Again, the existing bug on this discusses that.

(In reply to Boris Zbarsky (:bz) from comment #1) > I think we have an existing bug on this. In the absence of a bug number, I'll respond here. > I'm also not sure that the DOM has the information to do this right given > current imagelib APIs. :-moz-broken matches IMGs showing the broken image placeholder, so that can be used as an interim means of 'format not supported' IFF network transfer was successful and the actual file is neither corrupt nor truncated. Significantly corrupted IMGs in select formats (see below) will fallback to the broken image placeholder, and thereby match :-moz-broken. Note that this does not work if the file is truncated. :-moz-loading matches SVG IMGs that are IMG.complete = true, but are corrupted or truncated, and as such show a loading image placeholder, so that can be used as an interim means of IMG.complete = false for SVG. However, partial (or attempted?) decoding does not show a broken image placeholder. Every file type supported by firefox (as evidenced from the "control" original unaltered image) if truncated, does NOT show the broken image placeholder (although SVG does curiously show a loading image placeholder). More detailed findings as follows: // CONTROL Group Loading Placeholder: SVG As Decoded: BMP, BMP2, BMP3, CUR, GIF, GIF87, GROUP4, HISTOGRAM, ICO, ICON, JPEG, JPG, NULL, PCT, PJPEG, PNG, PNG24, PNG32, PNG8, PREVIEW, VID, X Broken Placeholder & Corrupt/Truncated Error: ICB, TGA, VDA, VST Broken Placeholder: (everything else) // CORRUPTED Group Loading Placeholder: SVG As Decoded: CUR, ICO, ICON Broken Placeholder & Corrupt/Truncated Error: BMP, BMP2, BMP3, GIF, GIF87, GROUP4, HISTOGRAM, ICB, JPEG, JPG, NULL, PCT, PJPEG, PNG, PNG24, PNG32, PNG8, PREVIEW, TGA, VDA, VID, VST, X Broken Placeholder: (everything else) // TRUNCATED Group Loading Placeholder: SVG As-Decoded: GROUP4, HISTOGRAM, JPEG, JPG, NULL, PCT, PJPEG, PNG, PNG24, PNG32, PNG8, PREVIEW, VID, X Broken Placeholder & Corrupt/Truncated Error: ICB, TGA, VDA, VST Broken Placeholder: (everything else) Interestingly, for the control files in the formats reported by Firefox as corrupted/truncated, ImageMagick display did not report errors for either the control or corrupted versions (although the corruption was visually evident). It did confirm errors with the truncated versions of these files however. Also note that the only attribute set on the IMG tags in this test was SRC. Each file was saved with the extension matching the type as listed above. Explicitly setting TYPE attribute may change some results... > Again, the existing bug on this discusses that. Sounds like an interesting discussion. Hopefully the bug number can be provided -- particularly as this bug is currently flagged as both DUPEME and Blocks. Tried searching for such a bug prior to filing this one, but to no avail.

Boris, did you perhaps mean bug 513541?

Bz, see comment 3, please

I actually meant the bug on setting complete=false for images where imagelib stops decoding partway through.... But this bug as originally filed does seem similar to bug 513541.

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046 Move all DOM bugs that haven't been updated in more than 3 years and has no one currently assigned to P5. If you have questions, please contact :mdaly.