Recap of Add-on-Con

Article
12/17/2009

We’ve just returned from Add-on-Con, an annual conference for browser add-on developers held at the Computer History Museum in Mountain View California. The add-on development community is an entrepreneurial bunch of people and it’s exciting to hear about what they’re working on. Herman Ng, Christopher Griffin, and I were there to present and chat with people. Matt Crowley was also in town so he was able to stop by for part of the day.

Herman spoke about best practices to improve reliability and performance. This topic really resonated with the audience. It’s clear developers want to deliver a great experience to customers by building cool features, having great reliability and performance, and getting exposure in the IE Add-on gallery. Based on the amount of interest we saw, Herman will be reworking his presentation into a series of blog posts starting early next year. So you don’t have to wait, I’ll give you two of Herman’s quick tips for add-on developers now.

Get crash reports for your add-on from Windows Quality Online Services (Winqual). This is a great resource for discovering and debugging crashes in your product.
Post your add-on to the IE Add-on gallery. Developers click “join” and then click on your username to upload add-ons.

My presentation covered how to build Webslices (msdn), Accelerators (msdn), and Search Providers (msdn). These extensions are a great way to connect your customers with your services without the risk of introducing performance or reliability problems. You can also build and deliver them with a little bit of XML and markup so you can connect users with your site or service in hours rather than weeks.

Thanks to everyone at OneRiot, GetGlue, and YooNo for organizing such a great event!

Paul Cutsinger
Principal Program Manager
Internet Explorer

Comments

Anonymous
January 01, 2003
I hope it would be work well not only for the user to compete other emerging browsers. This deficiency in IE is being cached by other companies.
Anonymous
December 17, 2009
The comment has been removed
Anonymous
December 17, 2009
I wish Microsoft would simply re-engineer IE or better yet start from scratch and make a new broswer; but don't call it IE. Too many people have negative associations with that name. Call it some nice simple name that is not too cute and doesn't have any negative connotations nor negative acronyms. And make it support web standards like HTML5 and WebKit. And make it fast fast fast fast fast. As is obvious, most people hate to wait for anything. This is why Chrome and Firefox and Safari are gaining in popularity while IE market share is dropping.
Anonymous
December 17, 2009
Giba: don't believe the hype in the echo chamber. IE may have lost a point or two of marketshare over the last few years, but it still has twice as many users as all of the other browsers put together. For many people, Internet Explorer is the Internet, and it has fine connotations, for the rare people who even know what a browser is. Edward: Documentation on how to build "on demand" extensions for IE (toolbar buttons, menu items, and ActiveX controls) has been documented on MSDN for over a decade now. Web Slices, Search Suggestions, and Accelerators (which are basically on-demand) are also reasonably well documented there.
Anonymous
December 17, 2009
Matt: Here in Germany, Firefox has recently surpassed IE in market share. Thus, it's not just a "hype" that's happening. The driving force behind that development here is that the two highly influential German computer magazines "c't", which is for IT pros, and "Computerbild", which is a tabloid for home users, have been recommending Firefox as the top browser for the last 2 years. Computerbild had a browser test recently: Firefox was rated best, IE last. And we can read again and again: "Why should you switch? Firefox has much better add-ons, such as efficient ad filters". Although I personally prefer IE (I'm an IE add-on developer), I have to admit that IE just cannot compete with Firefox regarding add-ons. If you tell people about IE's advantages (tab isolation, for example), this often doesn't seem to matter to them because they cannot "see" this feature. Another cause for the migration trend is that Germans are very concerned about security in general ("German angst"), and IE still is regarded of being more unsecure than Firefox. Of course that's no longer true, but every patch day, Windows users see important security updates for IE, which regularly reminds people that IE is vulnerable. Firefox sees more security related fixes than IE, of course, but they are delivered as neutral new Firefox versions, not intimidating home users. On the other hand, Germany has the fastest adoption rate of Windows 7 world-wide, and so there's hope that lots of German Windows 7 users may rediscover the great IE that's in Win7.
Anonymous
December 17, 2009
I would like to know if IE team is evaluating a migration from Trident to Webkit or Gecko engine. Any news about that? Thanks
Anonymous
December 17, 2009
The comment has been removed
Anonymous
December 17, 2009
@Matt: according to StatCounter, IE's market share in the US is now 53.39%. 'Only a few points' down from 95% in 2004. @notAnOpenSourceFanboy: Trident is great at... what?

Rendering speed? Not exactly (depends on case).
ECMAscript? Not really (slow).
DOM support? When will event bubbling be supported, when will dynamic DOM inside tables?
UI speed? When will loading a tab and a couple add-ons not take several seconds?
XHTML? Still not supported.
Security? It got much better, true. Still far from perfect.
Stability? Well, after you remove all add-ons, reset all browser settings to default, and scrap OEM settings away, you may not get a crash any more. I tried IE 8 with all latest patches on 32-bit WinXP, 32-bit Vista and 64-bit Win7; in all cases, I managed to crash it within a few minutes with a couple of toolbars installed.

Anonymous
December 17, 2009
@Mitch 74 - IE has used event bubbling since IE4.
Anonymous
December 17, 2009
The comment has been removed
Anonymous
December 18, 2009
@Will: I always confuse the two. I meant event capturing, my bad. IE's event model has another problem: how do you know which element 'caught' the event? In the W3C model, the 'this' keyword on the event handler function designates the element itself. In IE, you need to refer to event.srcElement - but then, event.srcElement always refers to the first element that captured the event, not to the element actually handling it (see http://www.quirksmode.org/js/events_order.html for a complete explanation). This makes, for example, mouseover effects (extended help bubbles and tooltips) impossible to handle for non-top elements (say that you create a function that displays the content of a tag's title inside a tooltip tha tfollows the mouse; a single 'span' or 'strong' tag will remove the tooltip in IE - something that other browsers handle much better). Working around this requires:

either creating a 'title' for all children that don't have one, and copy their parent's, then register an event handler on each one of them (this will probably cause leaks in IE if you use an AJAX page)
or only use this method on top-level elements. This means:
development is difficult,
functionality is restricted.

Anonymous
December 18, 2009
The comment has been removed
Anonymous
December 18, 2009
Can i use VB.Net for creating addons. Where to find some getting started or walk throughs
Anonymous
December 18, 2009
@AutoComplete: Using .NET is not recommended for building IE add-ons because of the expense of loading the framework into the browser process. There's a quick discussion of this over at http://blogs.msdn.com/ieinternals/archive/2009/08/21/agcore-addon-hangs-Internet-Explorer.aspx If you're just playing around and prototyping something for your own machine, see http://code.msdn.microsoft.com/SpicIE
Anonymous
December 18, 2009
@Mitch 74 - do you have a sample page with this behavior? Have you tried mouseenter in place of mouseover?
Anonymous
December 18, 2009
"IE has used event bubbling since IE4" wrong message.
Anonymous
December 18, 2009
thanks @Matt for sharing your thoughts. Anyway i would like to hear an official response from the IE team about this. Still waiting...
Anonymous
December 19, 2009
The comment has been removed
Anonymous
December 19, 2009
And, I forgot to add, Giba is right: Don't call it IE. Too many negative connotations. Most of my twenty-something friends wouldn't touch IE with a 10-foot pole (as the saying goes). Most of them used to use Firefox, but are switching to Google Chrome because it is even better than Firefox. Yes, it doesn't have as many addons as Chrome but it is faster and more secure. As Giba says, people hate to wait. People want speed. Next time you turn on your PC or laptop, does the boot up time bother you? Do you wish it booted up faster? If so, then you already are aware of how long it takes to start a piece of software. Well, same thing applies to browsers. One of the reasons that I upgraded to Vista (and soon to Windows 7) from XP is that I found that Vista booted up faster (I know that some people found the opposite was true for them. But it is true for me.)
Anonymous
December 19, 2009
@exIEFan, why do you think the IE team would bother to provide an "official" response listing all of the silly things that they're NOT doing? The VP of Windows already showed off the IE team's first few weeks of progress on the new version of Trident at the PDC last month. @GinaB, you're living in an echo chamber. IE is a browser used by nearly a billion people. Surveying a set of tech-savvy 20-somethings isn't a good way to get a representative sample of anything.
Anonymous
December 19, 2009
The comment has been removed
Anonymous
December 20, 2009
The comment has been removed
Anonymous
December 20, 2009
The comment has been removed
Anonymous
December 20, 2009
@Mitch 74 > how do you know which element 'caught' the event? window.event.srcElement (IE event model); evt.target (W3C DOM 2 event model) for final element after event bubbling phase; evt.currentTarget for element being traversed: this one has no equivalent in IE event model > In the W3C model, the 'this' keyword on the event handler function designates the element itself. "this" is not best used here; you want to use evt.target as a correspondent equivalent to event.srcElement > In IE, you need to refer to event.srcElement - but then, event.srcElement always refers to the first element that captured the event, Not the first but the final (destination, targeted) element after event bubbling phase, once bubbling has been completed and the event has reached its targeted element. > not to the element actually handling it It would have to be currentTarget but as you rightly state, there is no equivalent in IE event model. http://www.moneyshop.fr/eventmodels.html Many code instructions are not best in that webpage. 1- If IE7 is to be supported, then setAttribute() should be avoided everywhere. curtag.setAttribute("id",'infobubble'); can be replaced with curtag.id = "infobubble"; without any loss www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/html.html#ID-63534901 2- If iB (iB for infobulle meaning tooltip) sole purpose is to display only text, then resorting to innerText and innerHTML can be safely, conveniently avoided, removed. Just use createTextNode() and childNodes[0].nodeValue etc... and you'll reduce cross-browser forking code. DOM 2 CharacterData interface attributes and methods are very well supported in IE 6, IE 7 and IE 8. Why make editing/modifying the text of that tooltip more difficult? 99.9% of the time, innerText and innerHTML can be better replaced, removed, avoided with true web standards DOM attributes without any loss or problems. 3- initCommon() is called at window loading, not at document loading. Now, browsers compensate this but it's still a mistake. Under normal and strict conditions, a script can not and should not be accessing document elements or creating new ones (like curtag, iB, infobulle, ct) before the document has been fully loaded. Window and document are not loaded synchronously, simultaneously. I recommend to remove addEvent(window,"load",initCommon); and just add <body onload="initCommon();"> I am sure, absolutely convinced that your webpage can work as expected in IE 7 and IE 8. Remember that IE beta feedback had a very annoying DHTML tooltip function. Also, your webpage goals as far as tooltip is involved could be made working without event models, just by using CSS. E.g.: www.gtalbot.org/BrowserBugsSection/MSIE8Bugs/WrongContainingBlockOfAbsPosInline-1.html regards, Gérard
Anonymous
December 20, 2009
> Not the first but the final (destination, targeted) element after event bubbling phase Sorry, I got that mixed up in my mind. You're right: it's the first in IE event model. And it's the "middle" phase in the DOM 2 events model (eventPhase == 2; eventPhase == AT_TARGET). regards, Gérard
Anonymous
December 20, 2009
@Gérard, it's nice to see you back here "contributing" to the conversation with your usual level of discourse and demonstrating your firm grasp of fiction writing. I'm guessing that the school holidays must have come 'round and there's nothing else to do when you're back at your parents' house?
Anonymous
December 20, 2009
@Matt: I've been lurking on the IE blog for sometime. You seem to be the resident troll who camps this blog and flames everyone who asks a sincere question or expresses a criticism of Microsoft. This is a tacky way to support the company and its IE browser. The "rabid IE fanboy who hates all criticism" defeats the purpose of this blog and increases the negativity of the discussion. Each time you post, you derail the comments and trigger a flame war of petty insults. I assume you have no official connection to Microsoft and you are merely an overly-enthusiastic IE fan who mistakenly believes that spamming questioners with insults serves a constructive purpose. It doesn't. Perhaps you should temper your posts and find a more constructive way to craft your responses. Turning down your "Hostility Dial" from 11 to 1 would go a long way.
Anonymous
December 20, 2009
ted, you must be new here, since I'm fairly new to commenting on this blog, and while there's plenty of hostility here, little of it is from me. If you'd actually been reading here any length of time, you'd recognize that there are few "sincere questions" nor very many worthwhile "criticisms" either. There's a lot of ranting and gnashing of teeth from fanboys of less popular browsers who curse the unfairness of the real world. So, yes, I recently have tired of reading the dreck and falsehoods in the comments and have momentarily taken up the banner of calling out the misrepresentations and outright lies that are posted therein. It's ultimately as pointless as the ranting from the other side, of course, but it's a pleasant enough way to waste a moment here or there.
Anonymous
December 20, 2009
@Gérard: my point was two-fold:

IE's event model is limited compared with the W3C's, and quirky anyway
working around a few (not all) of its limitations is possible (you demonstrated it), but still incomplete and it requires ungodly amounts of code to do something that the W3C event model accomplishes with 'true' for addEventListener's useCapture=true. As for IE's market share, it varies so much depending on how, where, when, is someone farting in a server's direction or whatever when it is being done that no one can come up with a reliable figure. 25% is conservative - yet a reasonable consensus.

Anonymous
December 20, 2009
@Ted: my thoughts exactly. @Matt: by making fun of Gérard, you're at the same time discrediting the IE team, since they acknowledged his contributions (in a past article). Or maybe they just appreciate his fiction writing skills, who knows.
Anonymous
December 20, 2009
@Matt - Ted is right. You are quite rude in your comments. Gerard is very knowledgeable and can express himself in pleasant terms, as is Mitch74 and several others. You, on the other hand, just seem to want to annoy people by disregarding everything they say as false and inaccurate, also that we should accept IE as the "one true browser". While you're totally entitled to your opinion - bear in mind the old addage, it's not what you say but the way that you say it.
Anonymous
December 21, 2009
The comment has been removed
Anonymous
December 21, 2009
The comment has been removed
Anonymous
December 21, 2009
@bluscarab "Shouldn't IE be PRE-LOADED with all available plugins that the web supports?" ... That's where I stopped reading. Have you really been developing for 25 years? Maybe it's time to retire. I don't think you realize how many plugins exist, and regardless of the fact most users don't need them, IE wouldn't even be able to start if you had that many. That's almost like saying Windows should come with all existing programs ever (and run them on Windows startup while we're here).
Anonymous
December 21, 2009
@Mitch, onchange probably doesn't work the way you think it does in Firefox either: https://bugzilla.mozilla.org/show_bug.cgi?id=126379
Anonymous
December 21, 2009
@Paul: the problem isn't with how often IE fires the event (that's it, I've found back the bug report I wrote down a while ago): it's how the element's value behaves that required the workaround. Actually, IE does fire the event quite often (more often than Firefox, which mostly follows the RFC, while Webkit/Opera follow IE's firing frequence). But there is a problem with the SELECT's value when using 'change': if you have another function (NOT the event handler) that looks at the element's value after the event fires but before its event handler completes, this function gets the element's previous value instead of its current (displayed) value (in essence, the element has two values simultaneously). This doesn't happen with other browsers, even those that follow IE's way of firing the 'change' event. One workaround is to force 'blur' on the element when running non event handler functions (for example, by shifting focus), or simply use 'click' (which doesn't exhibits this problem but otherwise behaves like 'change' - even on keyboard events, which is incoherent).
Anonymous
December 21, 2009
The comment has been removed
Anonymous
December 21, 2009
@Mitch 74 - I set up a demo, that displays the intended titles for the various elements in both IE7 and IE8, at: http://willpeavy.net/playground/showtitles.html I used jQuery, which provides a nice abstraction so I only needed to write a very simple script.
Anonymous
December 22, 2009
The comment has been removed
Anonymous
December 22, 2009
The jQuery lib I used is hosted at - http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js - which is a widely used source across the web, and is therefore already cached by a large number of users before they even visit my site. Also, when the demo is viewed in IE8 without JScript - you can still see the title attributes, as intended, since the default browser behavior is to display the title attribute in a tooltip. So, depending on how a demo like this might be used in a real world scenario - you may not even any JS for it at all.
Anonymous
December 22, 2009
The comment has been removed
Anonymous
December 22, 2009
@Mitch 74 > We, as web devs, must spend countless hours circumventing IE bugs, improper implementations, special cases and proprietrary features, through compatibility libraries, specific code development, tricky debugging, that no_other_browser_causes! Mitch, I've never used compatibility libraries and I've never recommended one. I know how the event model works in IE. I know for certainty that your webpage code is not optimal, has a few mistakes, misunderstands a few things, resorts to unneeded declarations in CSS, resorts to strange decisions, etc. I do not know for sure what exactly you want to achieve to begin with. Maybe you should explain all this in a web programming forum discussion newsgroup like comp.lang.javascript: you would get help there. regards, Gérard
Anonymous
December 22, 2009
The comment has been removed
Anonymous
December 22, 2009
@Gerard - I think Mitch intended the compatibility library comment towards me, since I used a jQuery powered function to solve his bubbling scenario. The power of libraries like jQuery, MooTools, Dojo, etc is that I was able to come up with a cross-browser script in less than 5 minutes - just by writing a few lines of code. ...I think the most interesting thing about this though is that modern browsers (including IE8) display title attributes as a tooltip by default. So if displaying title attributes is the aim, then only basic HTML is needed.
Anonymous
December 22, 2009
@Will If the compatibility library is there to work around browser bugs, browser flaws, then such compatibility library acts like a crutch for short-term and does not serve a proactive goal/approach. It's not a real solution for everyone involved on the web (manufacturers, authors, users). If the compatibility library is for cross-browser with IE7 and IE8, then it's not a real solution for everyone. IE has to support properly all of the mature and stable web standards: DOM 2 Core, DOM 2 HTML, DOM 2 Events, ECMAScript 3.1, HTML 4.01, CSS 2.1, etc... so that we wouldn't/won't need to resort to a compatibility library (or code forks or complex js acrobatics) now/in the future. If the size of the compatibility library is huge (like over 10KB), if its functions are long, complex, indecipherable for ordinary web authors, then a compatibility library is not a solution: it's a nightmare. If half of the compatibility library is to support IE5.x, IE6, IE7, Firefox 1.x, Opera 7.x, Konqueror 3.5.x, Safari 1.x, etc.., then such compatibility library wrongly replaces/substitutes the need for users of such browsers to upgrade their browser versions, to keep their browsers updated. Manufacturers should fix their browser bugs (and implement mature, stable web standards) while users should keep their softwares updated. Where does a compatibility library fit into such equation? How can a compatibility library reasonably fit into such equation? regards, Gérard
Anonymous
December 22, 2009
@Gerard - In the world of software development life cycles, cost management and deadlines - JavaScript libraries are a very real and very useful solution. They are very effective at abstracting away the need for browser specific programming in modern web applications. I predict that within the next couple of years we will start seeing modern web browsers integrate the major JS libraries as native to their script interpreters (or compilers). Because the handful of major JS libs are so commonplace now, browsers could get a huge performance boost by implementing this.
Anonymous
December 22, 2009
I am currently in contact with some of the IE staff, have even built test cases for some of the newer bugs I found in IE8. While it is true that IE8 is not nirvana for WebDevs, I consider it a step into the right direction and will help MicroSoft at every opportunity to create a browser that will at least reach, at best even outperform in terms of speed, usability and standards conformance all other browsers. Currently they concentrate on features, but in the background, a lot of work is going into the rewrite of the JS engine, for example. I know that there will be some more Versions than IE9, IE10 and IE11 to come this far. But at least they are on the way. Greetings, LX
Anonymous
December 23, 2009
The comment has been removed
Anonymous
December 23, 2009
"Why do you or would you need to resort to a compatibility library in the first place, to begin with?" To reduce development time. "What's the real problem, real issues here being addressed and being solved by using a compatibility library?" The real problem is creating web-based software. The problem being solved, is being able to create it efficiently. "To work around browser bugs in various browsers and browser versions? To compensate for browser versions like IE8 which miserably fails at many DOM test suites on mature and stable DOM TRs? To work around many DOM 2 Core bugs, DOM 2 HTML bugs in IE8? To continue to support bug-ridden dinosaurs like IE6? To support very buggy browsers like IE7? To overcome/compensate lack of very cosmetic presentational/stylist properties like border-radius (rounded corners), text-shadow, etc.?" The term "bug" is all relative. Perhaps the standards bodies have created flawed drafts? "Deployment, implementability, debuggability: how complex, easy-to-grasp are such compatibility libraries?" If you know JS, the major libraries are easy to learn. "How big (filesize) are such compatibility libraries? How cpu+RAM hungry (footprint) are those compatibility libraries? How many/much setTimeout, setInterval, event handlers is there in such webpage?" Depends on what exactly you use, and how you use it. When building web apps for the enterprise, you usually have a managed environment where you know exactly what system resources will be. "Are you trying to do a DHTML-driven "snowflakes randomly falling in background" effect in your webpage?" No. "If browser manufacturers all support mature and stable web standards (HTML 4, CSS 2.1, DOM 2 interfaces, ECMAScript 3.x) and if all users keep their browser softwares updated, then why would you need to code thanks to a compatibility library?" If I lived in a fantasy world where 100% of users had the exact same browser, I would still use a library for the simple fact that having a nice set of objects and functions makes it easier to develop, maintain, and scale applications.
Anonymous
December 23, 2009
The comment has been removed
Anonymous
December 23, 2009
Gerard: I too would like a pony. May I move to your fantasy world?
Anonymous
December 23, 2009
The comment has been removed
Anonymous
December 23, 2009
The comment has been removed
Anonymous
December 24, 2009
The comment has been removed

Share via

Recap of Add-on-Con

Comments

Additional resources