144263 - Need backend for mimetype plug-in association

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Plug-ins, defect, P2)

Description

[rubydoo123]

Need to support a mechanism to allow mimetype assocaition with a particular plug-in.

Comment 1

[Peter Trudelle]

How is this going to interact with the MIME type mappings in
Prefs/Navigator/Helper Apps?

Comment 2

[Peter Lubczynski]

There are two ideas I have so far:

1. Use nsIMIMEDataSource and add const usePlugin=5 to nsMIMEInfoHandleAction in
nsIMIMEInfo. Possibly use the same mimetypes.rdf or make a new
plugin_mimetypes.rdf. For each nsIMIMEInfo, create a nsPluginTag from that info
or DLL pointed to, if possible, and give it priority over any "scanned" plugins
found during plugins.refresh(). An embedder or app UI could provide these
mappings similar to the way the helper apps dialog works today. They can already
get exisiting mappings from the DOM navigator array. We could possibly even ship
with certain plugins in a white/black list. (Real in components on white list
and Beatnik on black list, black list means preferredApplicationHandler = nsnull)

2. Make the DOM object navigator.mimetypes[0].enabledPlugin writeable (and
report correctly when read) such that one could choose which plugin was mapped
to which mime type by simple assignment. We'd still need some way to internally
store this info, possibly in the appreg or prefs.

Comments, ideas, suggestions?

Comment 3

[Peter Trudelle]

Could you please coordinate this with Bill Law?

Comment 4

[Boris Zbarsky [:bzbarsky]]

What modifications to nsIMIMEInfo would need to be made for solution #1, other
than the constant definition?

Comment 5

[Peter Lubczynski]

If a separate data source is used for embedded plugins vs. helper apps, then I
think we can swing by with only the constant change.

If the same data source is used then I think nsIMIMEInfo will need a new  
attribute for a default embedded plugin handler.

Comment 6

[rubydoo123]

*** Bug 141402 has been marked as a duplicate of this bug. ***

Comment 7

[Peter Lubczynski]

We really need a good plug-in manager back-end. Hopefully the fix for this bug
will also superceed any for bug 109739. We need to get away from using the
fragile application registry.

Comment 8

[Peter Lubczynski]

--->serge
plug-in manager work

Comment 9

[rubydoo123]

*** Bug 88114 has been marked as a duplicate of this bug. ***

Comment 10

[rubydoo123]

moving to 1.4 beta, plug-in branch work

Comment 11

[Peter Lubczynski]

-->peterl

Okay, new idea:
Use the existing nsIDOMPlugin/sArry and nsIDOMMimeType/sArray since it provides
lots of identification info about the plugin but have new interfaces (frozen for
embedders) that could be QI'ed to for controling these objects.

Comment 12

[Michael Buckland]

Discussed in edt.  Plussing.

Comment 13

[Matthias Versen [:Matti]]

*** Bug 150990 has been marked as a duplicate of this bug. ***