Comments on: Making Extension Development Easier

By: Bob Anderson

Bob Anderson — Wed, 11 Feb 2009 13:26:22 +0000

XMLHttpRequest supports responseText and responseXML. There is no responseHTML attribute. I have to brute force parsing with REGEX.

By: Jorge

Jorge — Mon, 09 Feb 2009 17:56:36 +0000

I agree with the previous comments. I’d like to generalize John’s point 3 to this:
We need a clearer guide as to how to make an extension. The current XUL tutorial is *not* an extension development tutorial. We need something that users can follow easily, giving them access to common practices, frequently used code snippets, etc.

And, of course, an IDE would be more than welcome. A set of recommended and maintained plugins for Eclipse or Komodo would work just as well.
FUEL was a good step, but it’s still very lacking IMO. I also liked the direction Labs was taking, with modules like the logging and observer objects. Those are quite useful.

By: robcee

robcee — Mon, 09 Feb 2009 17:32:33 +0000

that is quite a list!

I’d like to follow-up with a plea for better development tools. Chromebug is useful as a debugging tool, but what I’d really like to see is an integrated IDE for experimenting with code on the fly. An Eclipse-style workspace for executing JS/XUL code. It’s already interpreted, so doing this shouldn’t be that hard. Some experimental extensions get part of the way there, but there’s nothing cohesive and usable by itself.

I think to go along with the better tools, better abstraction from the underpinnings of XPCOM would help a great deal. FUEL was a start towards this kind of separation layer, but we need to keep going with it.

By: Curtis Bartley

Curtis Bartley — Mon, 09 Feb 2009 00:39:04 +0000

Better error messages. And by “better error messages”, I mean, you know, that there actually *are* error messages. I’ve found the required RDF files to be the worst offender on this count, but there are many other places where it’s a problem. Actually, now that I think about it, the RDF files themselves are a total pain in the ass. Don’t fix them, just out right get rid of them. Drive a stake through them and set them on fire. I understand why they’re there, but there’s just got to be a better way. Something as simple as replacing them with JSON might work. Well, JSON plus good error messages when you get something wrong. And you will get something wrong.

By: johnjbarton

johnjbarton — Sat, 07 Feb 2009 06:16:49 +0000

Not in order of priority.
1. Extensions are stored in deliberately obscured locations. eg the cryptographic name of extension directories, eg the use of UUIDs
2. Extensions rely on URLs with deliberately obscure relationship to the files system. chrome urls.
3. Much of the documentation on extensions encourages pointless practices that confuse and slow developers, eg UUIDs, jar files, too many variations in the directory structure.
4. Error messages for syntax or runtime problems often do not come out anywhere.
5. Error messages are most often incomprehensible, even to mozilla experts.
6. Error messages often don’t have file names or line numbers that make sense.
7. Files are sometimes named by chrome urls sometimes by file urls.
8. The rules for when the browser has to reloaded vs a window or a file are largely unknown.
9. The documentation site is artificially structured and overly verbose.
10. The overview documentation is very old and one never knows what to trust.
11. The documentation of the security system is almost not existent.
12. Generally the API caters to the the obscure over the easy. It is heavily influenced by C++ needs but most extensions are in Javascript.
13. The development tools are broken or under developed.