Firefox 3.1 and the respective XULRunner will sport a significant Javascript performance increase through an optimization called tracing by compiling frequently used code paths to native code using a built-in just-in-time (JIT) compiler unit.

Also, I want to highlight a quote by Brendan Eich, inventor of Javascript:

Eich says that Mozilla wants to "get people thinking about JavaScript as a more general-purpose language" and show them that "it really is a platform for writing full applications."

More details in the article

The following link points to a nice summary of how the chrome registry works which flew by on IRC. Note that this information pertains only to Engine 1.8 and up (Firefox 1.5 and later).

The Chrome Registration

I've mentioned this also in Under chrome's influence.

One problem facing Javascript developers is this: Your class model is spread across multiple Javascript source files. Class A depends on B, C and D. You are now faced with the problem of including the correct Javascript source files in all applications which use class A.

In ordinary HTML/XUL, you have a series of <script src> tags in all applications using class A. When class A starts requiring class E, you have to edit all HTML/XUL files again and manually include class E. And of course, it is very likely that you will miss one place or two which causes parts of the application to break. This is a problem which should be solved at the language level, but is not addressed at all so far in ECMAScript.

Continue reading "Solving the Javascript include problem"

If you implement an XPConnect interface in Javascript (e.g. nsITreeView if you don't want to use RDF to display data in a tree), you might need to access properties or methods inside your javascript object which are not part of the interface.

This can be easily achieved using a special object property.

Continue reading "wrappedJSObject"

Let's say you have massive amounts of Javascript.

Let's say you want to make the logic contained therein available to another language.

How would you go about that?

What we chose was compiling Omar Kilani's php-js extension which makes Mozilla's Javascript engine available as PHP extension.

This was totally sufficient in our case to extend existing testing procedures around the Javascript code. Developers can now run "make test" on the development server which will cause Javascript code to be tested. Thus we have incorporated something which was originally manual client-side testing into a completely automated test system.

Additionally, we will be able to avoid writing the same business logic in two languages. Instead, common parts can be written in JS and executed from another scripting language.

There are also modules for Perl and Python which embed the SpiderMonkey JS engine. Feel free to post links to other bindings.

For some time now various packages have been available to directly evaluate JS code written in Emacs in Mozilla -- without any reloading.

The newest approach is from Massimiliano Mirra called MozRepl. It promises to break us free from the write/save/restart/test cycle. What it currently does is this: You load/write a piece of Javascript code in Emacs, copy it into a Emacs buffer, send this buffer to the so-called JS shell server on the Mozilla end where the JS code is evaluated in a specific Mozilla window.

Further resources include:

JS Shell Server
Intro to JS Shell Server

Now, what from I can tell this just evaluates a piece of JS in some arbitrary Mozilla window. You cannot edit a specific JS source file in a running XUL application just yet. Now, would not that be cool? We really need a remote debugging protocol for Mozilla which includes manipulating JS objects and thus functions. I'd love to hear your comments on why this has not happened yet.

..well, almost.

If you look at bug 294122, you will notice that support for MSYS has been added to Mozilla's build system.

The relevant build notes are here:
Building with MSYS, Attachment 184389

"Just running "make clean" on Cygwin takes almost 6 minutes, vs only 1 minute with MSYS."

MSYS is a Minimal UNIX-like SYStem from MingW. Together with msysDTK (developer toolkit), it can replace cygwin as the base Windows build environment.

The big advantage of MSYS is speed. If you have ever built Mozilla on Windows, you will have noticed the abhorrent performance of Cygwin's make. make forks (or spawns as it is called in Win32) itself many hundred times during the course of a build which takes ages to complete. In comparison, MSYS is much more light-weight, zooming through the Makefile hierarchy like there is no tomorrow.

MSYS and msysDTK are fairly complete for this task. /bin/sh, CVS, make, vim - all the basics are there.

As the bug report notes, an iconv check has been recently added to Mozilla's configure. So, unless you install iconv separately, you currently still need cygwin. Perhaps iconv could be added to the msysDTK or be made available otherwise to address this.

And here is how you get the Mozilla control to work inside IE.

Continue reading "Trick 17 with XUL and IE"

This weblog has referenced the Mozilla SQL extension already multiple times. In this entry, you will find some actual code which uses that extension to provide a simple Mozilla-based client for a local or remote database. I will explain the source code from bottom to top, so be prepared -- we will dive right in.

Continue reading "SQL Console in Mozilla"

For writing API documentation, there is hardly anything better than (a) either having the documentation inline along with the code or (b) having separate staff do the hard work of keeping the docs up-to-date. Because most of us don't have the luxury of (b), we get to settle for (a).

Continue reading "JSDoc: Javadoc for Javascript"

From reading Adam Lock's Mozilla ActiveX Project page it appears that it should be already possible to have Internet Explorer run XUL applications. Has anyone tried that yet? I'll definitely look into this over the next few days. I just wonder whether applications will be able to gain security privileges comparable to the chrome environment (probably not). This would help selling XUL to companies wishing to continue their standardization on IE as sole client.

Any takers for Bugzilla entry #321099?

I suspect the bug is just too esoteric. It is always reproducible. Is not there enough data in the report? Or is there already too much? The testcase is absolutely minimalistic.

If you want to play with XULRunner, you can start using the Mozilla 1.8-based nightly builds. They are available for Linux/x86, Win32 and MacOS X.

XULRunner is the light-weight, stand-alone run-time for Mozilla-based applications. It is Mozilla without the browser.

As such, it can feature the whole range of Mozilla technologies, including extensions such as SQL support for MySQL/PostgreSQL/SQLite etc.

With XULRunner, you can make your XUL-application look like another desktop program. In addition to that, XULRunner does not contain the overhead of a slicky Firefox browser. You probably won't miss the bookmark feature in a XUL application.

To get started, visit this tutorial.

Mozilla is a very flexible beast. We will have a quick look at the various ways to deliver an application to your users.

Continue reading "Delivering XUL"

There are various ways to test applications. For GUI applications, you have the following options:

Continue reading "Testing XUL applications"