One of the least understood concepts in the Browser Plugin world is — browser plugins.  What they are, and even more: what they are not.  Probably at least once a week I answer a question somewhere on a forum or on the comments on this blog and say “You can’t do that with a plugin; you need an extension”.

Many people confuse plugins and extensions in the browser world. They sound like they should be the same thing, but in fact they are very different.

What you can do with a plugin

A plugin is, quite simply, a third party library that “plugs in” to the browser that can be embedded inside a web page using an <embed> tag or a <object> tag.  Many of them then draw pretty pictures or animations, though that’s not required.  Many allow you to talk to them through javascript, though that’s not required.  In short, a plugin affects only a specific page in which it is placed.

Examples of common plugins include:

• Macromedia Flash
• Microsoft Silverlight
• Apple Quicktime
• Adobe Reader (at least this includes a plugin in addition to the rest of the application)

Some plugins respond to a mime type and can run in place of the page, such as Adobe Reader, which allows you to view PDF files in your web browser.  Again, however, it affects only that page, and no others.  In Firefox, Chrome, Opera, and Safari, these plugins are usually called “NPAPI plugins”, since they are written using the NPAPI.  In Safari, you could also use a Webkit Plugin.  In Internet Explorer you would do this with an ActiveX Control.

What a plugin cannot do

Plugins have to either handle a mime type or be embedded into a web page.  They don’t get put there automatically. They don’t create toolbars.  They don’t affect browser menus.  They don’t know about tabs, or even about other pages in the same browser process.  They don’t make coffee, tea, or hot chocolate, though they could be written to control an external appliance to do so if you really wanted.  They don’t automatically process the content of every web page loaded.

“But wait!” I hear you all cry.  “We have seen these magical things done! (well, except the hot chocolate machine)”

“Yes,” I reply.  “Those are extensions.”

Extensions

Extensions, or “add-ons”, can often do these magical things.  They can add onto the browser UI, process pages that the browser loads.  They do all sorts of things.  However, they are not the same thing as plugins; they affect the web browser itself, not really the page.  They may affect a page as well, of course.  In fact, you can even put a plugin inside an extension, at least in Firefox.  However, if you write an extension for Firefox, you’ll probably have to write it again for Chrome, Safari, and IE… one for each.  Perhaps there is a framework out there for writing portable extensions, though.  It’s not really my area of expertise, so I don’t know.

Examples of extensions / add-ons:

• DownThemAll for Firefox
• Firebug for Firefox
• Google Voice extension for Chrome
• Let there be Comic Sans for Safari

And many, many, many more.  Extensions can be written in different languages depending on the browser.  In Firefox you can write them in C++ or javascript, and on Internet Explorer you write them as special ActiveX controls called Browser Helper Objects, or BHOs.

An extension could contain a plugin, but a plugin can’t contain an extension

One very common way to install a plugin in Firefox is to use a .xpi file.  This is an extension.  It may have a NPAPI plugin inside of it, but it is still an extension.  It will not work on other web browsers, even though your NPAPI plugin may work perfectly fine on Chrome and Safari if installed in another way.

Conversely, a plugin by nature does not include an extension.

FireBreath

Nearly a year ago now I began a project called FireBreath, which is a cross-platform browser plugin architecture.  FireBreath is, frankly, awesome. You can literally get a plugin up and going in under 10 minutes if you already have everything installed.  That means you can spend your time doing other more important things, like actually developing your functionality, rather than spending all your time figuring out how to deal with the plugin APIs.

That said, FireBreath is a cross-platform browser PLUGIN framework.  It does not create extensions.  It will never be able to create extensions.  If you need an extension, you need something else.

When not to use a plugin

Finally, and this is a topic that people seem to think is a little strange coming from me, there are many cases when it is not a good idea to use a browser plugin.  In fact, a good rule of thumb is that if you can do what you need to do without one, don’t use one.

Why?

• There are no really good ways to install browser plugins that will work 100% of the time
  • XPI install only works on one profile in firefox
  • CAB install only works in Internet Explorer and is sometimes a little unreliable
  • ClickOnce works only in Windows and only if .Net is installed
  • Java installers only work reliably and consistently on Mac OS
  • MSI or EXE installers while being the best method IMHO require a little more work on the part of the user, and the average user is… less savvy than you are, shall we say.
• Plugins have to take into account a large range of hardware types
  • If you use graphics libraries such as OpenGL or DirectX keep in mind that every graphics card works a little differently with these technologies.  You will run into weird cases where your plugin doesn’t work on someone’s computer.  If your luck is like mine, that computer will belong to an executive at a fortune 500 company (yes, that happened to me.  no, it wasn’t fun)
• Plugins don’t work until they have been installed
  • This is a major limiting factor to uptake of your site.  Many users don’t want to install yet another plugin on their machine, and many get lost in the incredibly complicated task of downloading and running the installer.

Moving on

If all of those things haven’t convinced you that what you want isn’t actually a browser plugin — great!  That’s why I’m still posting about this stuff.  Despite all the reasons not to use a plugin, there are also a lot of cases where it’s a good idea. Browesr plugin development can be a lot of fun!  Good luck!

Firefox 3.6 has removed support for XPCOM plugins.

This means that if you use XPCOM for your javascript interface (i.e. you have an IDL file on your npapi plugin, you us nsScriptablePeer, etc) your plugin will no longer be able to communicate with javascript in Firefox 3.6.

Thus I repeat advice that I have given in the past: Never, never, *never*, *ever* use XPCOM for your javascript interface in your plugin.

There might conceivably be reasons to use other aspects of XPCOM in a plugin, that might even work in other browsers. At present, I don’t know of them. Please enlighten me if there are (cookies?).

Oh, yeah, and FireBreath now has linux and mac support (experimental) as well as windows support (stable). Come join the fun. http://firebreath.googlecode.com

Thank you. :-P

I’ll be up-front about something here; I don’t particularly like ActiveX.  I understand a lot of the reasons for creating it, and I won’t go so far as to claim that it shouldn’t exist or anything like that; in fact, it does very well for certain types of things.  The main thing I don’t like about it is the complexity; it’s not something that you just pick up and start using one day.  You have to do a lot of research to understand what is happening, and though I’ve been working on ActiveX Controls hosted in Internet Explorer for over a year now, there is still a lot I don’t understand about what is really happening under the covers.

Because of this, I am a big fan of NPAPI.  I think it’s a great technology.  It’s simple.  It’s straightforward.  It provides an interface for one purpose, and that is to allow 3rd party developers to write browser plugins.  It’s great.  But, there is a problem: in my world, you can’t just say “I like Firefox better than IE, so I’m not going to support IE.”  Why?  I will make no claims here about security, usability, viability, or even disability of any browsers.  I will simply refer to one statistic: according to the w3schools browser statistics, Internet Explorer accounted for over 25% of the total web traffic every month last year.

So we find the classic challenge of all browser plugin developers: Internet Explorer only supports ActiveX controls, other browsers support NPAPI, and a plugin written for one isn’t neccesarily going to be easy to just port to the other.  Thus was born FireBreath, in an attempt to solve this issue.  Today, however, I want to address only one piece of the solution that we use in FireBreath:  How to create a scripting interface that will be “write once, run anywhere” on web browsers.

Common Scripting Interface

When I first began working on plugins, I worked on a project that had 3 seperate defintions of the javascript interface to the plugin.  One was for Mac, one for Internet Explorer on Windows, and one for Firefox on Windows.  The IE version was defined in an ActiveX .idl file and implemented in an ActiveX object.  The Firefox/win one was defined in an “XPCOM” .idl file and implemented in a nsScriptablePeer object (copied from a sample plugin from the mozilla source), and the Mac one was defined using NPRuntime and wrapped the XPCOM class.

This was, in short, a nightmare.

The problem I was initially trying to solve is that we had some APIs that had to be used differently on Mac and Windows, and they differed in less noticeable ways between Firefox and IE on Windows.  Don’t get me wrong — it all worked just fine.  However, from a maintenance point of view, this was certainly not optimal.  I could give a lot of meaningless history here, but eventually I came up with an idea that I dubbed (at that company) the Common Scripting Interface — a class that contained all the aspects that a good javascript object would need, but was not specific to any one browser.

Down with the IDL

Okay, this is where I’m going to start raising a lot of eyebrows.  I respectfully submit that using an IDL, as it is defined by Internet Explorer, is generally a bad idea on a control intended to be used from Javascript.  Why?  Simply put, Javascript is a dynamic language; when you pass parameters around, they are not type constrained.  Most javascript functions don’t care if you give them an integer, a string, a bool, or something else; they just use the parameters they are given.  Of course it’s a bit more complicated than that, but Javascript inherently is dynamic.  Thus, it can be important to have the ability to use a dynamic interface on a plugin that interfaces with it.

I hasten to remind you at this point that making an interface dynamic just for the sake of it being dynamic is a bad idea.  However, there are many use cases where you may have members (particularly properties that expose other javascript objects) that may only be named and become accessible at runtime; it’s too late to add something to the IDL.  I believe this is part of the reason that we have settled on NPRuntime on Gecko-based browsers, and Microsoft created an IDispatchEx interface to better support it on ActiveX.  Thus, we have all the tools we need to create a dynamic interface, and I have loosely patterned it after the NPAPI/NPRuntime interface, which I consider to be a fairly good interface for browser plugins.

What is JSAPI?

If you have looked at all at the FireBreath project that I have been working on for the last several months, you may have looked at or seen reference to the JSAPI class.  JSAPI stands for Javascript API.  JSAPI is intended to be a Javascript compatible object written in C++.  It relies heavily on the FB::variant class, which essentially is a class that you can put any datatype in.  If there is enough interest, I can blog more about that type later, but suffice it to say it’s very similar to boost::any but with data conversion tools built in.  A JSAPI object (an object that extends FB::JSAPI) provides all functionality that a Javascript object should, whether it is used or not.

What does a Javascript object do?

Let’s take a big step backwards now.  Forget anything you know about Browser Plugins or ActiveX Controls.  Forget anything you even know about C++, Java, C#, Logo, or any other language, even, except Javascript, HTML, DHTML, and CSS.  Those are the tools of the browser.  When we design the interface for a Browser Plugin, we shouldn’t be thinking like a C++ developer.  We should be looking at it the way we would if we were writing an object in Javascript; we should provide the interfaces that we would expect to find, and use the tools and syntax that we would expect to find in Javascript.

So, let’s look at what a Javascript object can do:

• Javascript objects can have methods that accept parameters and return a value

  • var coolData = plugin.doSomething(1, 1, 2, 3, 5, "right now");

• Javascript objects can expose properties that a caller can get or set:

  • var oldName = plugin.name;

  • plugin.name = "Some cool name";

• Javascript objects can provide events, to which a caller can attach an event handler in the syntax of their browser:

  • plugin.addEventHandler("click", function() { alert("The user clicked on me! Ouch!"); }, false);

  • plugin.attachEvent("onclick", function() { alert("The user clicked on me! Ouch!"); });

When you write it out like this, it doesn’t seem like much; remember, though, that a property of a javascript object could return any primitive datatype, an array, or even another javascript object, itself containing methods, properties, and events.

The JSAPI Interface

One additional thing to remember about a Javascript Object (now taking into account what we know about C++ as well) is that we don’t control the lifecycle of a javascript object.  What that means is that your plugin may go away before Javascript is done with the object that you gave it.  So, if that object uses any references to your plugin, (And what plugin javascript object wouldn’t? It’s the interface to the page, right?) you need to have a way to deal with not only cleaning up your object even after the plugin goes away, but making sure that the javascript object somehow finds out that the object it depends on is gone and invalidates itself in some way.  One way to do that is by using Shared pointers and Weak pointers, but that’s a topic for another day.

Like the NPObject and IDispatch types that provide its interface with the browser, JSAPI is reference counted, so that it will get destroyed whenever the browser.  Here are the method prototypes from JSAPI.h to satisfy the requirements mentioned above.  You can also look at the full source of JSAPI.h if you want.

Methods

// ...
    virtual bool HasMethod(std::string methodName) = 0;
    virtual variant Invoke(std::string methodName, std::vector<variant>& args) = 0;
// ...

Not much is required; one call to find out if the method exists, one to invoke the method.  Notice that the arguments is passed in a STL vector of type variant; you can pass any datatypes in here, but that will be limited by the Browser-level wrapper that converts the arguments from the browser datatype (VARIANT on IE, NPVariant on firefox) to the JSAPI variant datatype.  I’ll discuss this in more detail in a later post.

Properties

// ...
    virtual bool HasProperty(std::string propertyName) = 0;
    virtual bool HasProperty(int idx) = 0;
 
    virtual variant GetProperty(std::string propertyName) = 0;
    virtual variant GetProperty(int idx) = 0;
    virtual void SetProperty(std::string propertyName, const variant value) = 0;
    virtual void SetProperty(int idx, const variant value) = 0;
// ...

You’ll notice one strange thing right off the bat here; there are two of each method.  One takes a std::string for the first parameter, one takes an int.  Any thoughts on why?

Imagine the following code:

for (var i = 0; i < plugin.files.length; i++) {
    alert(plugin.files[i]);
}

This is a pretty standard piece of javascript code, right?  Array access notation is pretty common in Javascript.  Javascript, however, treats everything as an object of one kind or another. An array to javascript is really just an object with numeric properties.  Similarly, we need to be able to support numeric properties for array style access.  That is why we have extra property methods for a property identified by an “int”.

Events

// ...
    virtual void registerEventMethod(std::string name, BrowserObjectAPI *event);
    virtual void unregisterEventMethod(std::string name, BrowserObjectAPI *event);
    virtual void registerEventInterface(BrowserObjectAPI *event);
    virtual void unregisterEventInterface(BrowserObjectAPI *event);
    virtual BrowserObjectAPI *getDefaultEventMethod(std::string name);
    virtual void setDefaultEventMethod(std::string name, BrowserObjectAPI *event);
 
protected:
    // Used to fire an event to the listeners attached to this JSAPI
    virtual void FireEvent(std::string eventName, std::vector<variant>&);
// ...

Events are by far the most difficult piece of this whole class; we have to make allowances for multiple methods of registering events and multiple browsers’ methods for keeping track of the handlers. The BrowserObjectAPI type that you see used here is also a JSAPI object, but one that wraps a browser object (an NPObject or a IDispatch object, depending on the browser).

There are three different ways an event can be registered (at this point in time):

1. Through a “user-defined” event registering method implemented by our browser scripting object wrapper (this is used by all objects on firefox and all but the root object on IE).
   • The BrowserObjectAPI object will essentially be a method that we can invoke by calling InvokeAsync with empty string (“”) as the method name
2. Through the Connection Point interface on an ActiveX Control (obviously used on the root object in IE)
   • The BrowserObjectAPI object will be an object on which we can invoke a method of the same name as the event it is attached to
3. Through a property of the same name as the event (old-style javascript events, as in “document.onload = ….”
   1. The BrowserObjectAPI object will essentially be a method that we can invoke by calling InvokeAsync with empty string (“”) as the method name

These three types are the reason that we have three different register/unregister methods on the browser for events.  When FireEvent is called by the JSAPI child object (that you write), it iterates through all possible event handlers and invokes them asynchronously.  (Events have to be invoked on the main UI thread of the plugin, so the InvokeAsync call on BrowserObjectAPI automatically makes sure that is where it gets called; hence it’s async).

Next time

We have discussed and looked at the basic needs of the JSAPI object.  Part two will discuss the COMJavascriptObject class and the JSAPI_IDispatch helper class that constitute the interface between ActiveX and our JSAPI interfaces.  Part three will cover the NPJavascriptObject that provides the interface between NPRuntime and JSAPI.  Feel free to read ahead in the source =]

In the mean time, if you like where this is going and want to play with FireBreath and see JSAPI in action for yourself, there are some really easy getting started instructions on the FireBreath project page.

Update: See what is happening with FireBreath a year later

It’s been awhile since my last post!  Rest assured, that isn’t because I have lost interest, or because there was nothing to write about; rather, I was occupied with what I considered to be more important things.  If you’re reading this, you likely have already read my previous post, “Call for plugin Developers.”  If you haven’t, you might want to glance over it so that you know what I’m talking about =]

Firebreath has been sponsored by PacketPass, Inc.  I don’t have a web address for them, but I’ll post one later if they want me to do so.  The good news about that is that it means that unlike the vast majority of new open source projects, development of Firebreath is not going to halt before there is at least some sort of a usable project.

Who is working on it?

As you might guess, despite a lot of readers and comments on my last post, relatively few people have joined our mailing list and started helping.  I want to make particular mention of Georg Fritzsche of Germany who has been invaluable to me as a sounding board, as well as come up with some really cool ideas for improving Firebreath even more.  Aside from Georg, there are several others (Don, Jarom, Ben, … ya’ll know who you are) on the mailing list who have been a bit quieter, but nonetheless have been assisting with the brainstorming, planning, and in some small ways development of the project.  This may not sound like a lot, but for a special interest project such as this, I think it’s pretty good.  Of course, we can always use more help =]

Where we’re at:

While I’m not ready to release a “beta” version of Firebreath yet, we are getting really close.  In fact, it’s close enough that anyone feeling a little adventuresome shouldn’t have any trouble setting up a test plugin and testing the limits.  We only support Windows so far (sorry guys, it’s the platform I know best, and it’s the one my client needed first), but we support both Internet Explorer and NPAPI (Firefox, probably Chrome and Safari as well).

A brief list of supported features:

• NPAPI (Firefox, Chrome, Safari) support
• ActiveX/IE support
• Unified scripting API (define your objects for javascript use in one place, they work on all browsers)
• Easy manipulation of the DOM
• Event firing from the plugin into Javascript
• System event handling (mouse events wired, keyboard events can be easily)
• Basic framework for getting the HWND so you can do your drawing (needs to be fleshed out, but usable)
• Easy configuration of all plugin properties (such as Mime type, description, GUIDs, etc)

How to create a plugin with Firebreath

If you want to play with it (and please, please, please play with it and tell us what you think), it’s not too hard to get started.  On the firebreath google code page we have instructions on how to build it, including downloading of the source.  You can find it here: http://code.google.com/p/firebreath/wiki/BuildingFireBreath

Basic steps to build:

• Use Mercurial to download the source
• Use CMake to generate the project for either VS2005 or VS2008 (prep2005.cmd or prep2008.cmd)
• Open the generated solution file (build/Firebreath.sln) in Visual Studio and build it
• Run regsvr32.exe on the generated .dll (build/bin/Debug/)
• open build/projects/PluginTemplate/gen/FBControl.htm and play with it with firebug or jash

Basic steps to create your own Plugin:

• Copy projects/PluginTemplate to projects/YourPlugin
• Update pluginConfig.cmake — REPLACE ALL 6 GUIDs WITH YOUR OWN! — and set the mime type, plugin name, etc
• Rename TemplatePlugin.cpp and .h however you want and update the files so that it is your plugin
• Update factoryMain.cpp to create your plugin instead of TemplatePlugin
• Update your “PluginCore” implementation (TemplatePlugin extends PluginCore) to return the correct API type by editing createJSAPI() and copying MathAPI.h and .cpp to whatever you like.
• Update your JSAPI object (copied from MathAPI.h/.cpp) to have the methods, properties, and optionally events that you want
• Update CMakeLists.txt to make sure it includes any files that you need
• run prep200(?).cmd to regenerate the solution and project files
• build your plugin, run regsvr32.exe on it, and use build/projects/YourPlugin/gen/FBControl.h for testing

How to get more involved

We can use all the help we can get!  The porting effort to linux and mac shouldn’t be astronomical, but currently we have nobody to put on it at least until after 1.0 is out (RC1 planned for end of the year 2009, 1.0 planned for end of January, 2010).  There are a lot of little things that can be done by developers without a lot of plugin experience, as well as some real complex bugs and challenges that will require a bit more experience.

If you are interested in helping, even if just by making suggestions, asking questions, and making comments, please join the development list:

http://groups.google.com/group/firebreath-dev

Update: See what is happening with FireBreath a year later

I hereby issue a “Call for Plugin Developers” to the readers of the site. I know we are as of yet few, but I hope that some of you may be willing to help me.

I am quickly realizing that I need a plugin project from which I can quote source code; one that does the things that I am attempting to explain, and one that is not made up of code that is owned by a specific company or project.

Thus, I introduce to you all: FireBreath.

FireBreath

FireBreath is intended to be a cross platform browser plugin.  Currently, I plant to license this under the new BSD license.  This way, it can be used for commercial projects.  The targetted browsers are:

On windows:

• Microsoft Internet Explorer
• Mozilla Firefox (3 and up; we may add support for 2.x as well)
• Google Chrome
• Opera
• Apple Safari

On mac:

• Mozilla Firefox (see above note on versions)
• Google Chrome (when it is released)
• Apple Safari (3.x and up, intel only for now)

On linux:

• Anything that supports NPAPI plugins and Gecko SDK 1.9 or above (no firefox 2 for now)

What needs to be done

This is an ambitious project; I can help with development, and I can coordinate tasks.  I don’t have time to do it all myself, however, unless a company sponsers me; there is one that has shown interest so far, but nothing is certain.  Even if that happens, and a company wants this project enough to pay me to develop it, it will be far more successful if there are other contributors — you see, I don’t know everything.

In particular, I could really use a “strong right hand” who would be willing to head up the linux-specific part of the development, which despite 10+ years of linux experience is still my weakest point.  If there are others who wish to take ownership of other parts, that would also be great; for now, I will retain the final say on what goes in, because, well, I can.

If you look, you’ll find that there is no code up on the repository as of yet (at least, as of the time of this writing.)  I just started an ActiveX control this evening with the intent to implement FBControl, the ActiveX control portion of FireBreath.  As soon as I have a rough skeleton ActiveX control project done (which will happen sooner if I get a lot of developers wanting to help), I will start on the NPAPI portion of the DLL.  Even before I have that done, there are several small, relatively simple tasks that I could use help with.  In particular, I will not be using any code directly from the mozilla source tree and the plugin samples, so I need someone to write from scratch the NPN_ wrappers for all of the browser functions.

How you can help

For this project to succeed, we need all the help we can get.  If you would like to help, please send me an email at taxilian@gmail.com and introduce yourself.  Tell me:

• Who you are
• What you consider your strengths in this area are
• What interests you most about this project
• How you want to use FireBreath yourself (if at all)
• How much time you may be able to put in

I’ll take nearly anyone right now, though I will be carefully monitoring the code submissions to start out with; my project goals are:

• Reusable and modular
• Cross-platform (both in the browser sense and the operating system sense)
• Cleanly written
• Free and useful

I by no means want to be a dictator on this; I welcome help and suggestions from everyone.

Thanks!

Update

Last time, in Detecting the version of an ActiveX IE Browser plugin part one, I discussed the ToString() method of an ActiveX object, and how it is called when an ActiveX object is instantiated from javascript with the syntax:

var object = new ActiveXObject("PART1.PART2");

If you read my last post, then you will remember that if you don’t implement this function, you get the following message:

Object doesn't support this property or method

During my testing before, I had incorrectly assumed that this prevented the object from being instantiated.  However, all it really does is instantiates the object and then throws an exception.  So, you actually could, if you wanted, catch that exception and then check the error message.

Writing the code

So, if we wanted to write a function that would notify us when the plugin was installed, all we need to do is try this repeatedly until it works; however, we don’t want to overload the browser, so a setInterval or setTimeout would probably be appropriate.

Here is a function that I threw together that is similar to the one that I wrote for work.  I haven’t tested it, but I have tested the one I use at work, and they are pretty similar in all functional aspects, so it’ll probably work.

if (!ColonelPanic) { ColonelPanic = { }; }
 
ColonelPanic.ActiveXIdentifier = "ColonelPanic.AwesomePlugin";
 
ColonelPanic.WaitForActiveXPlugin = function(callback) {
    var plugin;
    try {
        if (new ActiveXObject(ColonelPanic.ActiveXIdentifier))
        {
            callback(); // You could change this to pass back a version number
        }
    } catch (e) {
        if (e.message == "Object doesn't support this property or method")
        {
            callback(); // it created it, but doesn't support .ToString()
        }
    }
 
    setTimeout(function() { ColonelPanic.WaitForActiveXPlugin(callback); }, 300);
};

Making it cross-platform

Now, if you are like me, you don’t want your plugin to work on just one browser; so, we’ll make another function that will detect what plugin type is supported and call the correct function.  We’ll save the plugin detection function for NPAPI (firefox) type plugins for another post — I have a lot to write about NPAPI plugins.

ColonelPanic.WaitForPluginInstall = function(callback) {
    if (typeof(ActiveXObject) != "undefined")
    {
        // Internet Explorer
        ColonelPanic.WaitForActiveXPlugin(callback);
    }
    else
    {   // other (firefox, safari, opera, chrome, etc)
        ColonelPanic.WaitForNPAPIPlugin(callback);
    }
};

Now, there is still one last task — we need a way of determining the actual version in case the plugin has updated since we last restarted the browser, to facilitate background updates. That will probably be my next topic =]

Blog site up

Well, ColonelPanic.net is up and running, and I guess that means it’s time to start posting!  The primary intent of this blog is to provide a place to post solutions to development and technical problems that we have been able to find only after a lot of research and testing on our own.  Google is a wonderfully useful tool for developers, but it doesn’t seem to do very well at producing information that hasn’t been written.  So, while we wait for the google engineers to correct this oversight, we decided we needed to take action to at least make sure that our hard-earned knowledge isn’t totally lost.

What got me started

So, as part of my gainful employment this week I have been working at improving our browser plugin install methods.  Move Networks has the most impressive online video player that I have ever come across (which is basically why I decided to work for them), but there are always things that can be improved with any system.  Recently my task has been to streamline our install process.

One of these days I will post details on how we have combined our (IE) ActiveX control with our (firefox) NPAPI plugin in the same DLL, but that will need to be the topic of a different post.

Finding a solution to a problem

One of the trickiest tasks with any browser plugin is to detect if the installed plugin is the version that you need.  This is made particularly difficult because there are multiple browsers and multiple browser types.  During my research I looked over the default installer that Microsoft ships with Silverlight and found a very simple solution to the Internet Explorer half of this problem.  Essentially, the packaged silverlight.js file instantiates the ActiveX control using javascript and then calls a method to verify the version:

control = new ActiveXObject('AgControl.AgControl');
if ( version == null )
{
    isVersionSupported = true;
}
else if ( control.IsVersionSupported(version) )
{
    isVersionSupported = true;
}
control = null;

In this example, version is passed into the function and indicates the lowest allowed version of Silverlight.  In our plugin, we want to do something similar — except in our case, we wanted to be able to just get the actual version.

How it works

So, the first question that we need to answer is: How does internet explorer know which ActiveX control we’re referring to with “new ActiveXObject(‘AgControl.AgControl‘);”?  Well, as it turns out, this can be configured in the system registry.  I found some documentation in the MSDN that covered several topics, including this one.  Essentially, there are two locations in the registry where an ActiveX control can be assigned to a “<Major>.<Minor>” name:

1. [HKEY_CURRENT_USER\Software\Classes]
2. [HKEY_LOCAL_MACHINE\Software\Classes]

If you want to register this for the whole system, then put it in HKEY_LOCAL_MACHINE.  Otherwise, put it in HKEY_CURRENT_USER, which can be written to without having administrator privileges.  The HKEY_CLASSES_ROOT key shows a combination of the two; a key that exists in both will be taken from HKEY_CURRENT_USER.  See this explanation from the MSDN for more info.

Implementation problems

Armed with this understanding, I set out to make it work with our ActiveX plugin.  I set up the registry keys, opened Jash, my favorate javascript debugging tool, and tried creating my plugin:

>> control = new ActiveXObject("QSP2IE.QSP2IE")
Object doesn`t support this property or method

That’s not real helpful!  ActiveXObject patently does support creating instances of an activeX object; my plugin is, indeed, registered under that name!  Why isn’t it working?  Well, that took some debugging.  I ended up creating my own method for the GetIDsOfNames method of the IDispatch Interface that ActiveX uses to expose members to the browser.  As it turns out, creating an ActiveX Object instance in this way calls the ToString() method on the plugin.  Gah! I haven’t found this documented anywhere (if you find it, please post a link), but I added it to the IDL of my plugin anyway.

>> control = new ActiveXObject("QSP2IE.QSP2IE")
"071300000030"

Success! It works!  Since my implementation of the ToString() method simply returns the version string, Jash shows me the output when it first creates the object.

The one downside so far is that if you update the DLL file while IE is still open, calling new ActiveXObject() again doesn’t get the new plugin version. This might end up being a showstopper for me!  We’ll see how it turns out.