Make unknown image formats find an extension to display them

RESOLVED WONTFIX

Status

()

enhancement
RESOLVED WONTFIX
12 years ago
5 years ago

People

(Reporter: vincent.deconinck, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) 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

Comment 2

12 years ago
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 → ---
(Reporter)

Comment 3

12 years ago
(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...

Comment 4

12 years ago
One other thing that would be extremely useful is the ability for web-designers to find out if a particular browser supports a certain image type. Is there such a mechanism? E.g. some javascript function to check a certain mimetype is supported allowing the designer to redirect to another page or substitute the <img src="blah.mng"> with something else.

e.g. does the following (RFC2936) exist and actually work?

   <SCRIPT LANGUAGE=JAVASCRIPT>
   <!--
   if (navigator.mimeTypes && navigator.mimeTypes.length > 0) {
     if ( navigator.mimeTypes["video/mng"] ||
          navigator.mimeTypes["video/x-mng"]) {
       // here if MNG extension exists
       }
     else {
       // here if MNG extension does not exist
       }
     }
   // -->
   </SCRIPT>

Sorry about 'hijacking' this bug, but it's a two-edged sword to get fairly decent support for unknown image formats...

Gerard

Updated

12 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 5

12 years ago
I don't see the need for javascript to handle multiple content types.
That's the reason for nesting object tags.
<object data="images/alpha_jpeg.jng" type="image/x-jng" title="My beautiful translucent jpeg">
        <object data="images/alpha_png.png" type="image/png" title="A translucent PNG - 10 times the size of the JNG">
          Your browser does not support displaying PNG or JNG - what a shame. The image was so pretty.
        </object>
</object>

Comment 6

12 years ago
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 ago10 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.

Comment 9

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