imglib does not gracefully handle unknown images sent with incorrect MIME types

RESOLVED FIXED in mozilla1.9alpha8

Status

()

defect
RESOLVED FIXED
12 years ago
12 years ago

People

(Reporter: eschew, Assigned: eschew)

Tracking

({dev-doc-complete})

Trunk
mozilla1.9alpha8
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 3 obsolete attachments)

Posted patch First approach (obsolete) — Splinter Review
Third-party image decoders only work correctly when images are sent with the correct MIME type. If the server sends an incorrect MIME type, then imglib eats the request and never passes it on to other decoders.

When loading an image from an <img> element, imgRequest currently does two things when trying to find a decoder. First, it uses content sniffing to try to detect common image types -- gif, jpg, png, etc. If that fails, it takes the mime type and tries to find a decoder registered with the contract id "@mozilla.org/image/decoder;2?type=channel_mime_type". If the server sends the correct mime type, then all is well. If, however, the server sends an incorrect mime type (such as "text/plain"), then imglib, finding that there is no decoder registered for type=text/plain, cancels the image request.

Attached is a patch that rectifies the problem. It creates a new category, "image-sniffing-services", under which third-party image decoders may, at their discretion, register nsIContentSniffer implementations. After imglib sniffs for the common types it knows about, and before it relies on the none-too-trustworthy server MIME, imglib queries the nsIContentSniffer implementations registered in the category to try to determine a MIME type.

One disadvantage here is that this approach may blur a line between imglib and necko. That sort of architecture decision is beyond my ken. On the other hand, it incurs zero performance penalty in the common case of gif/jpg/png images.
Attachment #276113 - Flags: review?(pavlov)
Attachment #276113 - Flags: approval1.9?
Posted patch Same logic, clearer comment (obsolete) — Splinter Review
This patch has the same logic as the previous, but the comment makes it clearer what's happening, and why. I think the structure of the code, with an explicit early return instead of a big if wrapper, better reflects the common and uncommon code paths.
Assignee: nobody → web+moz
Attachment #276113 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #277624 - Flags: review?
Attachment #276113 - Flags: review?(pavlov)
Attachment #276113 - Flags: approval1.9?
Sorry for the bugspam, I forgot to include imgRequest.h's diff in the previous patch.

On a side note, where's the proper place to document the addition of a category like image-sniffing-services?
Attachment #277624 - Attachment is obsolete: true
Attachment #277630 - Flags: review?(pavlov)
Attachment #277624 - Flags: review?
Attachment #277630 - Flags: review?(pavlov)
Attachment #277630 - Flags: review+
Attachment #277630 - Flags: approval1.9+
not sure where the best place to document it would be.  possibly on the wiki (wiki.mozilla.org) somewhere.
Keywords: checkin-needed
mozilla/modules/libpr0n/src/imgRequest.cpp  1.96
mozilla/modules/libpr0n/src/imgRequest.h    1.37


documentation should be on developer.mozilla.org... not sure where to put the docs for the new category off-hand. Ask dev-mdc perhaps?
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Flags: in-testsuite?
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9 M8
Keywords: dev-doc-needed
Posted patch as checked inSplinter Review
Attachment #277630 - Attachment is obsolete: true
Blocks: mng
Added some initial documentation on devmo, including pages for nsIContentSniffer and the image-sniffing-services category, with a link on the Firefox 3 For Developers page.
You need to log in before you can comment on or make changes to this bug.