A large part of my job at Mozilla is trying to make life easier for extension developers. In order to do my best, I need to understand the pains of extension developers. Up to now, I have been writing various types of extensions myself (sidebars, statusbars and components) to try to understand what an extension developer goes through. I even download extensions just to look at the code, trying to find comments like “hack” or “sucks”. But really, that’s not enough. So now I am asking extension developers directly:
What can Mozilla do to make writing extensions easier?
The title of this post mentions hacks, but I am interested in all aspects of extension development:
- Tutorials
- Installation / Updating
- Using frozen XPCOM interfaces/ components/ services
- Intergating into Firefox/ Thunderbird UI code
- Protecting against version to version breakage
- Documented best practices (or lack of)
- Anything else (extension related)
Feel free to leave comments on this post (preferred) or send to mark dot finkle at gmail dot com
The installation trigger seems to be poorly documented. I’m talking about the script you can put onto your webpage to make Firefox know the extension’s name and compatibilities before it is downloaded.
Chromatabs for Firefox uses a hack to colorize the Mac theme’s tabs — that should be easier.
Three things:
1) Documentation!
2) More Documentation! & Examples
3) Either include jslib, or create a simple lib for common tasks, such as pref read/writes, etc. A lot of code could be simplified, and the barrier to entry could be lowered with this.
I’m glad you guys at Mozilla are finally getting around to making the creation of extensions easier to understand. Over the years, I’ve really wanted create or be part of the creation of extensions, but it is very hard to be part of the process when there is such a high level to entry. The only good sources of information and help that I have ever found have been the following:
http://www.webmonkey.com/06/25/index3a.html
http://roachfiend.com/archives/2004/12/08/how-to-create-firefox-extensions/
http://kb.mozillazine.org/Getting_started_with_extension_development
http://ted.mielczarek.org/code/mozilla/extensiondev/
http://ted.mielczarek.org/code/mozilla/extensionwiz/
Now don’t get me wrong, the official documentation I’ve found at http://developer.mozilla.org/en/docs/Building_an_Extension isn’t incomplete or anything like that, but it looks like someone took a brain dump. If I was an intermediate C++ or Java programmer instead of a semiskilled web designer, I might have a chance to understand it, but as these documents stand right now, they are just far above my reading level.
Overall, more documentation and examples are need for those of us at the beginner level. The documentation should start out slow with basic code for a slightly simpler than average extension with “real world” examples to show how the different parts of an extension interact with one another and how they function inside of Firefox.
Get extension dependencies working better. Then we could do frameworks for extensions, and just require that framework.
Mark, next time I’m working on my extension, I’ll be sure to let you know the bugs I come across 🙂
It’s been over a year since I hacked on an extension (too long!). Anyways, last time I checked, the Drag and Drop API was confusing and buggy (as in, crashed Firefox), which meant that otherwise cool features had to be dropped. Documentation of some things needed/needs improvement, notably the interplay between HTML and XUL, and why, say, embedding cerrtain XUL elements in a popup would also cause a crash (it’s in bugzilla, but took a while to figure out that this was known behavior back then). For benefit of those playing around in content-land, I’d sort of like to see an architectural overview of content loading, to see how soon is too soon for script to be playing around with document objects as a page loads… but that’s rather specific to content policy impelementors I guess.
I’ll come back if I think of anything more.
As an amusing side note, here’s a flowchart I put together just before I burned out on Adblock: http://eschew.org/projects/adblock/architecture.png .
I’m just starting out looking into extensions after at least a year of following Mozilla activities and trying to get my head around the way things could be done.
I come from a HTML/Perl?SQL hacker background. I’ve essentially never touched desktop application coding. I wonder if there are other web hacks out there attracted by the HTML-like nature of XUL and the use of JavaScript as the real workhorse.
For me the biggest problem is the lack of a complete IDE. Your XUL Explorer came along at the most opportune time but it’s early days with that app obviously.
Apart from an IDE, I need a simple introduction to the Mozilla ecosystem. What can be done with it, what can’t be done with it? How far can I go without knowing C? What exactly is XPCOM and how does it relate to JS? I’m currently looking at all the nsI stuff and I don’t even know what nSI stands for! That half the doco is out of context or date, on xulplanet not MDC and lacks simple visual explanations really is a big problem.
The most simple adjustments like Last Updated dates on documentation pages would be mega helpful.
It seems that there is a massive learning curve between doing an XUL ‘old your hand’ tutorial and trying to find out which bits and pieces can be used to do what. Doing a hold-your-hand tutorial is only useful for helping people get their toes wet and build a bit of confidence. There needs to be a step beyond that which doesn’t throw people into the deep end.
Feel free to email me if you would like to hear more of the above.
I have to whole-heartedly concur with Robert Accettura on all three points and what pd said about an IDE.
If someone could create something like ThinG (XUL editor for Thinlet – slightly different than Mozilla XUL – http://thing.sourceforge.net/ ) then I think extension creation would take a giant leap forward. I know that a lot of people say that XUL is a layout language and that you don’t need a GUI IDE – that’s all well and good for those that have learned it already but that’s not going to help with new adopters.
It would make sense to post a similar post to dev-extensions and to the mozillazine forums (unless you did that already).
The correct use of max and minversions needs to be documented. I see far too many develoeprs not utilising the * version format (eg. specifying compatibility with Fx 1.5 – 2.0) and that hurts users.
Hi Mark,
I just came across your blog and I’m delighted to learn of your evangelist role. I came across your site because I am tacking a first-time extension development. So, I have a couple of thoughts, and welcome offline direct communications as well.
1. The traditional starting points such as Ted Mielczarek’s extension wizard (http://ted.mielczarek.org/code/mozilla/extensionwiz/) are great for overall code organization, but of course lack any real implementation details
SUGGESTION: More tutorial documentation!
2. Thus, for a newbie extension developer, the next logical step is to inspect code from exemplar extensions. Some of my favorites are Firebug, Web Developer and Zotero. The *.xpi and *.jar zipped format for code makes it easy to do code inspection. However (and soon!), modifying existing routines becomes a pain. The overlay mechanism means it is totally unclear which ids are inherited from the base, and which are new. Attempts to combine and modify XUL code from multiple sources runs into the problem of breaking essential internal references. After some days of inspection, I still don’t grok ids and best practices for naming ids. I also thought I understood the CSS differences between ids and classes, but am not sure they apply across the board to XUL.
SUGGESTION: Naming and coding standards (Pascal v camel v hyphened id naming, for example)
SUGGESTION: Better means to extract out the parent DOM ids (DOM Inspector or Firebug does not work on the browser DOM, and I have been leery of working directly with Firefox in code)
SUGGESTION: Document where to find critical parent ids in the Mozilla source
3. Quickly, things spiral from simple documentation to the real messiness of a working app extension. How does one create a bottom panel? Write to a sidebar? Set preferences? Employ a simple SQLite DB? Manipulate windows or layouts within the browser? Find exemplar combined XUL-JS-DTD-CSS packages?
SUGGESTION: I will shortly review your XUL Explorer, but it looks like the idea of self-contained “exemplary” code snippet packages could be taken considerably further
SUGGESTION: I myself am working on a basic “shell” template for extensions (with, hopefully, well documentated code) that can be installed as an XPI. Much more of this is needed.
Again, I wish you well. I think this technology is fantastic, and points the way to the future. If I may be of some assistance, please don’t hesitate to contact me directly.
Thanks, Mike
Mike–
Thanks for the detailed comment. I wanted to respond to as many of your points as I could:
1. Tutorials and Code Snippets are a good thing and we are working to create more of them.
2. DOM Inspector is a great tool for “spelunking” the browser for element IDs and structure. Yes, you can use it on the browser too, just type “chrome://browser/content/browser.xul” in the DOM Inspector’s URL field. I guess an MDC article would be nice.
3. I plan to keep evolving XUL Explorer into a suitable extension development tool. Feedback like yours helps keep me focused on it.
Thanks
Mark
What seems desperately lacking is someone or some initiative to ‘champion’ the cause of an IDE. Surely it should have the status of a core app like Firefox and Thunderbird?
What frustrates me the most is that there are so many pieces already there but nobody has integrated them.
Out of curiosity I wonder if even central MoFoCo employees like yourself know about all of these:
XULMaker – http://xulmaker.mozdev.org/
Firebug – http://www.getfirebug.com/
Extension Developer Extension – http://ted.mielczarek.org/code/mozilla/extensiondev/
DOM Inspector – http://www.mozilla.org/projects/inspector/
Venkman – http://www.mozilla.org/projects/venkman/
Luxor – http://luxor-xul.sourceforge.net/
Any of these – http://xul.sourceforge.net/
Plus I’m sure there’s more.
Am I missing something? Does the community think that plugins for Eclipse or another IDE will suffice?
If the Mozilla platform is going to explode, surely it needs something like VisualBasic 6? Something simple but powerful.