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)
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.
Comment 1•22 years ago
|
||
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.
Comment 2•22 years ago
|
||
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.
Comment 4•22 years ago
|
||
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.
Comment 6•22 years ago
|
||
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.
Comment 8•22 years ago
|
||
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.
Comment 9•22 years ago
|
||
> 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?
Comment 10•22 years ago
|
||
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.
Comment 11•22 years ago
|
||
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).
Comment 12•22 years ago
|
||
milestone changed to mozilla1.3alpha
Target Milestone: --- → mozilla1.3alpha
Comment 13•22 years ago
|
||
peter
Assignee: beppe → peterl
Target Milestone: mozilla1.3alpha → mozilla1.4alpha
Updated•15 years ago
|
QA Contact: shrir → plugins
Comment 14•13 years ago
|
||
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
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•