The default bug view has changed. See this FAQ.

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

RESOLVED FIXED in mozilla1.9alpha8

Status

()

Core
ImageLib
RESOLVED FIXED
10 years ago
10 years ago

People

(Reporter: Ben Karel [eschew], Assigned: Ben Karel [eschew])

Tracking

({dev-doc-complete})

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

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 3 obsolete attachments)

(Assignee)

Description

10 years ago
Created attachment 276113 [details] [diff] [review]
First approach

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

10 years ago
Attachment #276113 - Flags: review?(pavlov)
Attachment #276113 - Flags: approval1.9?
(Assignee)

Comment 1

10 years ago
Created attachment 277624 [details] [diff] [review]
Same logic, clearer comment

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

10 years ago
Created attachment 277630 [details] [diff] [review]
Same logic, clearer comment, with .h changes too this time

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

10 years ago
Attachment #277630 - Flags: review?(pavlov)
Attachment #277630 - Flags: review+
Attachment #277630 - Flags: approval1.9+

Comment 3

10 years ago
not sure where the best place to document it would be.  possibly on the wiki (wiki.mozilla.org) somewhere.

Updated

10 years ago
Keywords: checkin-needed

Comment 4

10 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
Last Resolved: 10 years ago
Flags: in-testsuite?
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9 M8

Updated

10 years ago
Keywords: dev-doc-needed

Comment 5

10 years ago
Created attachment 279331 [details] [diff] [review]
as checked in
Attachment #277630 - Attachment is obsolete: true
Duplicate of this bug: 374088
Blocks: 104906

Updated

10 years ago
Blocks: 18574
(Assignee)

Comment 7

10 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.