User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206) Gecko/20070222 SeaMonkey/1.1.1 Build Identifier: When the browser encounters an image that it cannot decode, an automatic search for a suitable extension to handle it should be launched, much like the plugins auto-install procedure. This would allow integration of various emerging or rarely-used image formats (MNG, JNG, DNG, ...) while hopefully avoiding 7-year long discussions such as the one in bug #18574 Reproducible: Always
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 374088
I don't think this is a duplicate -- the point is to find and install a plugin (e.g. for MNG) when it's needed, while bug 374088 appears to be about the extension API to allow image decoder extensions to fully integrate into the system as well as in-tree code. Modifying the extension API doesn't solve the problem of finding and downloading a missing extension that is needed. Reopening.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
(In reply to comment #2) > the point is to find and install a plugin An *extension*, to be precise (see comment 689 of bug 18574). Indeed, this bug is about automatic handling of unknown image formats in <img> tags, that is finding if a corresponding extension exists and, if it's the case, prompting the user for installation of this extension. If I'm not mistaken, bug 374088 is about the ability to implement such an extension...
Waiting for the day finding of an extension supporting "video/trojan" will be supported ;-)
I don't think this is especially useful, or worth the code it'd take to pull it off.
Status: NEW → RESOLVED
Last Resolved: 12 years ago → 10 years ago
Resolution: --- → WONTFIX
This would greatly increase the feasibility of extensions to support MNG, JPEG2000, JPEG XR and DNG and would be necessary for their practical use on webpages. IMHO, it would be a significant advantage for Firefox, similar to bug 16769.
Als, this bug was essentially WONTFIXed because no Mozilla employee wants to work on this bug ("We won't accept a fix because none of us wants to write one" - a logical fallacy). Such a closure is appropriate in a closed-source beta (like on Microsoft Connect), but not in a FOSS project.
This is not a feature that is generally useful enough for inclusion in core, and would not have benefits equal to the cost of developing and maintaining the feature. It has nothing to do with employment at all, and you have zero basis for such allegations. Just because someone is willing to write a patch doesn't mean we should take it. Down that path lies madness.
You need to log in before you can comment on or make changes to this bug.