Mozilla2:Improving Development Environment

Overview

Sometimes when you work on a project for too long, you cannot see the forrest for the trees. It seems like the good people, who have been working on Mozilla for so long, cannot see how esoteric the requirements for building an extension are. This could lead to a situation where Mozilla is losing potential developers based on bad first impressions. Because when you first experience XUL development, you must first experience the requirements to set up an app before you can even do "Hello World".

The purpose of this page is to bring together related claims from new XUL developpers who have a fresh perspective. The final aim is to ease the work complexity of new XUL developpers, and to make mozilla/firefox a great development environment, out of the box.

In this area, you may either point other developpers to a solution you found, or ask for an improvement. You can link to a specific page / newgroup thread to start a constructive discussion.

List of claims

Feel free to add items to the list below :

Few error messages

Description

When creating a package, firefox will fail silently if their's a
syntax error in one of the package description files.

Impact

Firefox, Packaging

Solutions, workarounds

Is there an option to make firefox more verbose ?

Improvements

Make the extension module more defensive. Add meaningfull messages.

No simple option

• Description

Currently, the requirements for setting up the project are very elaborate. There are too many boiler-plate items on the check list that have to be successfully completed. All of which can be assumed (see Ruby on Rails philosophy) but are potential blockers for new developers who silently pass up XUL because it looked like a lot of unnecessary pain.

• Impact

XUL Runner apps. Mozilla/Firefox extensions.

• Solutions, workarounds

None

• Improvements

Why can't it be as simple as passing a jar file to xulrunner/firefox bin on the command-line - the same way you pass a jar file to java bin.

Privileges / Security barrier

• Description

When one's developping a XUL app, he will soon face privilege issues. actually, many access to deep Mozilla functionnalities (as interacting with XPCOM) are restricted by privilege.

We understand that it is mandatory, but some privilege requirements have impact on functionnalities that do not obviously require security (like drag & drop for example).

Moreover, locally installed applications (extensions) have a special status, will full privileges that no remote application could ever get. Mozilla already embeds a signing facilities signing facilities Signed scripts or signed applications should be able to execute with full privileges, without prior installation.

This barrier may prevent the develoment of great online applications, as we already have for XUL extenstions.

• Impact

Remote applications.

• Links

This point is already being discussed here

The developer mode

dev extension proposal

Once mature, a KISS (keep it simple stupid) dev starter kit could be bundled with FF to tempt potential developers into "giving it a go". It could be accessed from the tools menu under "create my own extension".

• javascript on sidebar, setsome flags, no xul cache
• auto generate a skeleton extension based on a choice of templates
• click a "publish" button to produce an XPI along with a basic HTML page including a link to it.