The future of IE extension API / Framework

John C MCSD

I'm not trying to start some "this is better than that" kind of argument, so I hope no one interprets this in that way.

I've developed a few Firefox browser plugins. I love the ease of development that the Mozilla extension API gives you (once you figure out the file and directory structure). It allows an average programmer to create an extension with nothing more than notepad, and no compilers. Or if you want more power you can create a full Java compiled extension. And with the advent of Silverlight (and some creative hacking) you can create a C# extension. But the point is that almost anyone who has basic web dev experience can write a Firefox extension.

So recently I decided to write an IE plugin, and um...oh no. I dont want to write a C++ COM dll, I'm a .Net developer. Ok, I can write it in C#, but shoot...I have to port all the interfaces over to C#. Man...this is hard. Why Mozilla proved that it doesnt need to be hard.

So my question is this. What is the future, if anyone from the right MS team is reading this, if the IE plugin architecture. Will it continue to be a compilcated list of COM interfaces and registry hacks, or will IE move over to a much easier model, similar to what Mozilla has done

The reason is that there are thousands of really useful Firefox plugins (and 100 times that number of not-useful plugins). Almost any idea that I come up with for a useful Firefox plugin, almost asuradly has already been created. But the same can not be said of IE plugins, because it takes specialized and hard earned knowledge of C++ and COM. Its so compilcated and anoying to create one that there are very few.

If IE went to a more open, accessable model for their plugin architecture, IE users would have a plethora of plugin options.

IECUSTOMIZER

Hi John,

You are assuming that COM is the only way to make an extension for IE. Far from it. I have over 150 Command Bar extensions, most of which have been adaptations of FF and Mozilla extensions. You can even create Toolbars and Explorer Bars with nothing more than a html page. Only BHO's require a COM.

With enough searching I am sure you will find that someone has already written an Addon for such and such a purpose.

The problem with IE extensions is not that they are difficult to write (well not for the technically challenged), but rather that they are not centrally marketed like they are on mozilla.org.

The IE-Addons Gallery is quite extensive, but it is a real pain to publish your addon through downloads.com and whereas mozilla.org is an open source, IE is a proprietry product that understandably MS is not keen to see it tainted by malicious addons. The only free cheese is in a Rat trap.

When IE7 was in Beta, there was some concern for maintaining backward compatibility for some Addons, but now the new Browser has spurned innovations by developers to come up with new and novel additions to the list of IE extensions.

For me the biggest plus for extension development has been the inclusion of Windows Scripting in the OS builds. The biggest minus is the new behaviour of the Side Search Pane.

Regards.

John C MCSD

Hey Rob,
I did not know that. When I searched on IE Extension or IE addon, the top results are msdn articles that talk about COM APIs and C++. So just in looking around for 15 minutes it seemed like that was the only way to go.

So with just scripting you can add toolbars, status bar panes, right click menues, and sidebars in IE

IECUSTOMIZER

Hi John,

Well basically yes. It is only that C# is the flavor of the month at the moment. It depends upon what you want to achieve with your addon.

Command Bars and Menu Extensions(Tools & Help) have access to the browser and its children via external.menuArguments

eg.

var win=external.menuArguments;

var doc=win.document;

... I was going to go on and describe each of the main types of Addons, but that would be a bit long winded.

Instead, just visit my site http://www.iecustomizer.com and go for your life.

You see from my site that I do not publish any Toolbars or BHO's of my own. It is not that they are difficult to code (which they are, as this forum testifies), but that I have the opinion that they are unnecessary and are the root cause of annoyance of users. Market research indicates that the prime use of web browsers is for searching and the major search providers have long since published their own toolbar extensions to promote their services. The biggest annoyance of web surfing is popups. Most toolbar addons include a web search and popup blocking function.

This site http://www.conduit.com/ offers free toolbar customizations that include search customizations and a built-in popup blocker. IE7 has search discovery and its own built-in popup blocker. You have to ask yourself, well what else is needed out there that the browser does not already have.

A personal observation is that it is not so much the difficulty in writing an extension, but rather the difficulty in deploying it that is a hinderance to extension development. Once you have written one extension, you have the basis for creating an unlimited number. The C# sample toolbars testify to this. In the modern OOP IDE, inheritance allows you to compile and unlimited variation from a base class.

The conduit toolbars are written in delphi and just use xml to customize the basic stock toolbar.

One thing I am starting to notice in this forum, are deployment problems. It is easy to compile a 'hello world' sample, but it is another hurdle when it comes to deployment. The same principle applies though, once you have done one, the rest are variations.

I use my own proprietry utilites to create extensions. The number of extensions that I have published on my site testifies as to their efficiency. I hope to have them available for download, but on the other hand, open source is not going to keep me feed.

I don't think that the COM Addon model is going to change, just as ActiveX is not going to disappear overnight, they are core to MS's extensibility stategies. I do think however that the use of COM addins (Toolbars and BHO's) will decline with changes to browsers and computer monitors. Search, Popup blocking, Autocomplete and security enhancement is functionallity that is being built-in to the browser. Modern screens have a greater aspect ratio which is forcing GUI utility from height to width. You see all of this in IE7's design...

Regards.

jose.cervera

Hi,

but if you want to modify the DOM before showing the page to the user, is there any other way other than BHO

Regards!

IECUSTOMIZER

Hi,

Not necessarily so, but generally yes. You could have a separate process looking for the creation of new IE windows on a timer, hooking in and altering the dom in the beforenavigatecomplete, but this is an ugly application, which would degrade the performance of the browser.

There are some user settings that effect page rendering and ActiveXCompatibility flags can block Flash and other unwanted objects.

Regards.