In nsObjectFrame.cpp::Reflow(), we do some analysis of the clsid but do not take into account content meant for ActiveX controls (when the clsid equals some serial number and the codebase usually equals some .cab file). Right now, we only look for matches with internal XPCOM objects (tree view, toolbar, and appshell). We need to detect whether or not the object tag refers to an ActiveX control (based on clsid) and go through three steps: - First, determine whether we have a plugin that handles ActiveX controls (e.g. NCompass or Adam Lock's new plugin). We can base this on mimetype: application/oleobject or application/x-oleobject (this is what our old layout checked for). The ActiveX plugin handles other mimetypes like olescript and lpk files, so I'm not entirely sure what else we need to check for. If we do have a plugin, we need to create it and do the usual plugin things. - Second, if there is no plugin to handle ActiveX, we need to check for alternate content and invoke that if found. - If there is no plugin OR alternative content, we need to invoke the default plugin. I need to add a method to nsIPluginHost so you can find out what plugins are enabled for a particular mimetype. I'll also do the work of getting the default plugin working. Adam - please chime in here if have any input that I'm missing. I'm not too familiar with ActiveX.

ActiveX plugin support can be tested for with an #ifdef MOZ_ACTIVEX_PLUGIN_SUPPORT. If support is enabled, and the OBJECT tag has a CLASSID attribute, then it should be treated as as a plugin of type application/oleobject. Is this easy to do? Assuming that it is, it means that the same ActiveX plugin will work with OBJECT and EMBED schemes. The next task after that is for the plugin to acquire the initialisation parameters. For the EMBED tag, they are attributes of the form, e.g. <EMBED ... PARAM_Arg1=val1 PARAM_Arg2=val2> etc. For the OBJECT tag, they are child tags of the form <OBJECT><PARAM Name=Arg1 VALUE=val1></PARAM>...</OBJECT> etc. The second form requires that plugins can access the DOM so that it can inspect its child nodes.

I have completed all but the handling of alternative content (check for mimetype, default plugin support). The Object tag style params get passed to the plugin as part of the argn, argv params to NPP_New(), so there's no need to access the DOM for this info. Adam - when I try to build your plugin, it says that I need the Platform SDK. Would it be possible for you to provide the plugin and any support files in binary form so I can test it? I don't want to check in my changes until I have tested it with your plugin.

Changing QA contact to sujay

Alex, what is latest on this?

Hey I'm not the Plug-ins person....Paul, can you assign this to someone?

It is assigned correctly.

Sujay was referring to the assigning of the QA contact, I believe

This is pretty much done. I have tested it with the NCompass plugin, which loads, but does not display correctly. I need to meet with them to go over the problems, but I believe that as far as the object tag goes, it's complete. I'll check this in for M6, so moving to M6.

Adam, can you verify this?

Can someone tell me how to verify that this fix is in? Thanks.

verifying after confirming with amusil