Closed Bug 170349 Opened 22 years ago Closed 13 years ago

ActiveX control plugin should not hardcode the content types that it handles.

Categories

(Core Graveyard :: Plug-ins, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID
mozilla1.4alpha

People

(Reporter: jud, Assigned: peterl-bugs)

References

Details

Currently the ActiveX control plugin has to hardcode the content types that it
can handle in order to be invoced. We need to come up w/ a generic mechanism
that allows invocation of the plugin w/ out hardcoding content types; something
more generic.
See bug 133816 about getting the NP_GetMimeDescription entry point working on
windows like it is on other platforms so plugins can dynamically report mime
type. QT and plugger already do this but bug 125469 causes some limitations.
So how are you envisioning the activeX to get instantiated? Are we not focusing
on the presence of teh classid attribute? If so, then the clssid:nnnn value will
point directly to the appropriate plug-in. 
Content types can also be associated with controls. For example the
video/quicktime is registered in HKEY_CLASSES_ROOT/MIME/Database/ContentType as
requiring the {02BF25D5-8C17-4B23-BC80-D3488ABDDC6B} activex control.

In this instance the <object> tag might look like this:

<object type="video/quicktime" src="foo.mov"></object>

Assuming there was no QT plugin, in this instance Mozilla would invoke the
default plugin as there is no mention of the clsid.

If the control could say it handled certain types at runtime (which would
probably be a list defined somewhere), it could be invoked for objects such as this.
hmm, I believe the scope of invoking the activeX control was only through the
classid attribute and not through other object element encoding.
The scope of the activex plugin is to invoke an activex control whenever a clsid
is specified, or a clsid exists to handle some unrecognized content.

The plugin would maintain a strict list of what content types it handle (e.g
vendor foo says they're not going to implement a plugin so the activex plugin
handles the content instead), but there should be a way that it can publish this
list dynamically rather than being compiled into the DLL.
Adam,
Can your plugin return failure from NPP_New when the classid is not supported? I
think that may cause us to render the containing EMBED tag.
I can return a failure code if my plugin doesn't handle the control.
Alternatively perhaps you should not invoke the plugin in the first place if you
detect an embed tag inside an object tag.
It should not be just for a nested EMBED element, we also need to analyze a
nested OBJECT element that we can satisfy befoer popping back up to the parent.
Depends on: 125469
>  If we come up against content which specifies controls implicitly by content
type instead of a classid in the OBJECT tag then we may have to reconsider this
and bug 170349.


What about showing the default plugin when the mime type is not found or
rendering the alternate content inside the OBJECT tag? Do we always need to give
the Active-X plugin a crack at the mime type before showing the default plugin?
Perhaps this should be the default behavior in all cases. Would it be acceptable
to require authors to use the classid for ActiveX support in Gecko?
This issue is a little tricky -- there are cases where an object element used
like how Adam says in Comment 3 may be the *only* object tag, without a nested
embed tag or another nested object tag.
This is when an author wants to use only 1 object tag, which will invoke an
ActiveX control on IE and on other browsers (such as Moz' and Opera) will invoke
the NPAPI equivalent.
So if there's a content-type in the object tag, why don't we assume that the
author wants to go the NPAPI route?  As peterl says, we then allow the default
plugin to come into play, since if they are using a content-type, they must want
a MIME handler to be used as an alternate to the ActiveX control -- that is, the
NPAPI plugin.  
Hmmm... in fact, we should be smarter than that.  Here's thinking aloud:

If there's a content-type in the object tag, but NO NPAPI plugin to handle that
content-type, then we should let the ActiveX plugin invoke an affiliated ActiveX
control.  If there is an NPAPI plugin, then invoke that instead (and the ActiveX
plugin does nothing).  If there is no NPAPI plugin OR no ActiveX component, then
maybe the ActiveX plugin ought to download whatever's specified in the codebase
attribute of the object element (an ActiveX control in a CAB file, for example).
milestone changed to mozilla1.3alpha
Target Milestone: --- → mozilla1.3alpha
peter
Assignee: beppe → peterl
Target Milestone: mozilla1.3alpha → mozilla1.4alpha
QA Contact: shrir → plugins
The ActiveX embedding API was removed in bug 662023 and friends.

-> INVALID

[Filter bugspam on activexinvalid]
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.