Closed
Bug 391667
Opened 17 years ago
Closed 17 years ago
imglib does not gracefully handle unknown images sent with incorrect MIME types
Categories
(Core :: Graphics: ImageLib, defect)
Core
Graphics: ImageLib
Tracking
()
RESOLVED
FIXED
mozilla1.9alpha8
People
(Reporter: eschew, Assigned: eschew)
References
Details
(Keywords: dev-doc-complete)
Attachments
(1 file, 3 obsolete files)
3.27 KB,
patch
|
Details | Diff | 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.
Assignee | ||
Updated•17 years ago
|
Attachment #276113 -
Flags: review?(pavlov)
Attachment #276113 -
Flags: approval1.9?
Assignee | ||
Comment 1•17 years ago
|
||
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?
Assignee | ||
Comment 2•17 years ago
|
||
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?
Updated•17 years ago
|
Attachment #277630 -
Flags: review?(pavlov)
Attachment #277630 -
Flags: review+
Attachment #277630 -
Flags: approval1.9+
Comment 3•17 years ago
|
||
not sure where the best place to document it would be. possibly on the wiki (wiki.mozilla.org) somewhere.
Updated•17 years ago
|
Keywords: checkin-needed
Comment 4•17 years ago
|
||
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: 17 years ago
Flags: in-testsuite?
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9 M8
Updated•17 years ago
|
Keywords: dev-doc-needed
Comment 5•17 years ago
|
||
Attachment #277630 -
Attachment is obsolete: true
Assignee | ||
Comment 7•17 years ago
|
||
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.
Keywords: dev-doc-needed → dev-doc-complete
You need to log in
before you can comment on or make changes to this bug.
Description
•