The Inside Track on Firefox Development.

« New Feed Handling Feature for Testing | Main | Feed Content Now Visible »

May 5, 2006

The "Joy" of XUL?

Firefox's user interface is built using an XML grammar called "XUL" (for XML User interface Language). Shortly after the decision was made to switch to Gecko, the Netscape team began developing a web-based user interface toolkit for the new Mozilla browser. The rationale was that it would allow the application to be built for the variety of target platforms and toolkits once, rather than individually. Without going into a long history lesson that many
of you will already know from other places, this approach turned out to be trading one set of problems for another. But we ended up with some cool and ultimately useful technology as the platform stabilized.

The problem is this: almost all of XUL as it exists today hasn't changed much if at all since it was originally written in the charge to Netscape 6, and as a result the capabilities and problems with the platform reflect the quick cycle and shortcuts that had to be taken.

Today, we're in a difficult spot. XUL and the Mozilla platform at large allowed Firefox 2 to be built very rapidly and have many capabilities, including its popular extension system. Other projects like XULRunner have grown up too. The popularity of Firefox and the perceived flexibility of XUL to an outsider mean that now there are many extensions, and a growing number
of XULRunner applications.

Inconsistencies and Bugs

As I said earlier, very little work has been done on it over the years since the Netscape XPToolkit team moved on. There have been a lot of minor incremental fixes that have made many aspects of the system more stable, but significant bugs and critical failings remain. This is immediately obvious to anyone who has ever built with XUL but who isn't part of the "Mozilla community" where the sort of work that people do sort of self-selects towards the things that XUL is capable of. There is a web of inconsistency (for instance today a colleague of mine asked a question which pointed out that we have several different ways to get the "width" of a XUL widget: boxObject.width, width Attribute, and the width held by the computed CSS style of the object. The problem only gets worse if you extrapolate "widget" to include "top level window". There are also things that just don't work as they should, like layering any kind of complex widgets using the <stack> element (see creative workarounds in the Safe Browsing code).

The Solution

What really needs to happen is a holistic, top to bottom review of the XUL API with significant overhauls where necessary. This sort of review needs to be done from the point of view of "What do app developers expect from modern toolkits" not "what will be possible to implement within the framework of Mozilla". This is a culture thing we have to shake. This is in my opinion the
only way XUL has a chance at being capable of delivering the sort of applications that users will expect to run on their systems in the future.

There are many things that we could be doing now, things that aren't necessarily gated by the Cairo work that's going on, etc. These include building a more capable tree widget, revising APIs, etc.

Why aren't we doing things like this? Well, one reason is I think in many ways as a community we have come to think of XUL as a "frozen" thing, despite the fact that no review or freeze process was conducted on the API. What we're stuck with then is a lot of self-induced confusion and stop energy when it comes to making changes that push the XUL platform forward.

My Opinion

My opinion (just my own, and I know I'm controversial) is that we should break whatever we have to in order to get XUL into good shape. We never said this platform was frozen. We built (inconvient but effective) version restrictions into extensions as a result of this. We actively don't promise that folk using non-frozen APIs won't be broken by new major Gecko versions. So why don't we use this as an opporunity to fix what's broken and take the time to do the right thing by the platform, our developers, and ultimately our users?

I think we should do this to the exclusion of supporting the old XUL APIs. The reason for this is that by adding rather than replacing we increase the overall size and thus complexity of the code. Every time there are two different components that do similar things we raise the barrier to entry for new hackers and we frustrate people building on our technology.

As someone who spends a lot of his time building with XUL, I can tell you it's not a pretty picture. Over the years I have become accustomed to the quirks and I have formed little shortcuts in my brain that I apply when I run into problems. Not everyone has had a chance to do this, and I don't think that they should have to.

Developers Are Users Too!

These days, developers have a lot of platform choices when building their applications. Once you're familiar with XUL it can let you develop applications incredibly rapidly and within it lies true value. We need to take steps to not only to make sure it keeps pace with developments elsewhere in the software world but also to make sure that it lives up to what could be said as being its presently superficial promise of making application development easier.

Sidebar: On the Cairo Transition

Another thing I've noticed people saying a lot is "Oh that will be fixed once we switch to Cairo." and "We'll be able to do that in 3.0". This scares me. I have a very limited understanding of how most of layout works, but it's my understanding that if there's a bug in XUL, the bug is often in the XUL layer itself, or something else like the native widget code or the View system. Changes like the switch to Cairo may make possible a certain class of
toolkit features, but only if the bugs in the layers between graphics and the application developer are fixed.

Posted by ben at May 5, 2006 1:58 PM

Comments

What you've written could almost be talking about the application suite before Phoenix/FireFox was started.

Posted by: Ian Thomas at May 5, 2006 2:38 PM

This is something I want to pay very close attention to. I'm doing some work to extend the toolkit in my spinoff XUL Widgets project. XUL's one of the things about Mozilla that I care about.

Posted by: Alex Vincent at May 5, 2006 2:40 PM

I think this would be a very wise thing to do ...

Posted by: Anonymous at May 5, 2006 2:56 PM

"Developers. Developers. Developers. Developers. Developers. Developers. Developers. Developers." (sorry...)

Completely agree. Break it all!

Posted by: Hemebond at May 5, 2006 3:24 PM

There is definitely a "well-worn path" that works in xul, and stepping outside that path is a dangerous and scary proposition. I think this "holistic" review is long overdue. It's delay has meant that mozilla may be hard pressed to compete against the latest breed of toolkits available if it's not done very soon.

I've thought a lot about what the "perfect" toolkit would be, and how xul is so close and yet so far from achieving that goal. As you said, a lot of it is that it's design is old and therefore doesn't take advantage of the advances both in mozilla but also in the competition. What some of those competitors have done has been to make a more "designer friendly" toolkit, and I think that should be given a signficantly amount of weight in the review of XUL. Cairo/canvas, SVG, XForms, HTML5, XAML, etc. should all be considered, weighed and, where possible, integrated. You mention the treeview, I think it's far bigger than that and the list that follows is only scratching the surface:
infragistics like grid controls
ribbons like office 12
embedded tablet/pen support
improved html editing
a plethora of date/time/scheduling controls
better data binding and validation ala xforms
designer api (meta data added to the controls)
remote xul/security issues resolved
flow/grid/dock/canvas panels such as what's in xaml
xbl/xtf 2.0 and a clear separation of content from functionality

Not to bash, but I think a lot of the stagnation is due to the (perceived?) closed nature of the toolkit developers themselves - not the frozen nature of the api - which has limited the number of contributors who could have helped move the platform forward. A lot of work has had to happen around the edges of xul so as not to tread on turf that would require a toolkit review and therefore interminable delay. It may be helpful to consider alternatives to the past/current approach of maintaining toolkit. Just a thought.

I'm anxious to see toolkit/xul moved ambitiously forward in an organized way to compete against the likes of XAML. Thanks!
-woo

Posted by: Andrew Douglas at May 5, 2006 3:54 PM

I'm all for refactoring XUL and making the APIs easier to use. In my humble opinion, I believe that the real challenge for ensuring 3rd party/non-community developer adoption lies in making sure that the documentation is continuously up to date and versioned. The quirks need to be documented with the API and not just reside in bugzilla or in the newsgroups. Having two ways to do certain things isn't necessarily a bad thing as long as there is documentation that explains the various approaches or even just the canonical/recommended approach. I realize that this can be difficult if the API is still unfrozen and is a moving target, but if the velocity of changes to an API starts slowing down, then for the sake of developer adoption, maybe just calling it frozen and documenting it and its quirks and workarounds would serve us API consumers a lot better.

Breaking frozen APIs in subsequent versions isn't a big deal either as long as us 3rd-party/non-community developers are given the heads up on most of the API changes. Making such changes public as part of the roadmap would make our lives a bit easier. It would make the task of going to bugzilla or the newsgroups that much more precise and less time consuming. I'm in the middle of porting a XUL based application from the MOZILLA_1_7_X_BRANCH to the MOZILLA_1_8_0_X_BRANCH and there isn't really an easy way to figure out which APIs were changed other than maybe waiting for something to break at either compile time or run time.

So please, break it, fix it, do whatever needs to be done. As long as some authoritative documentation about those quirks, workarounds, shortcuts and other tidbits that goes with those APIs can keep up and be easy to find, it will give us outside developers the confidence to invest in XUL and stick with the Mozilla platform for the long haul. Armed with that, maybe we can also find this "Joy" you speak of in our own XUL projects.

Posted by: Paolo de Dios at May 5, 2006 4:09 PM

Break away!

"What do app developers expect from modern toolkits" is the right question but I would add that developers means developers, NOT ff/tb or other mozilla app developers. I've always felt like a second class citizen waiting for the next release because my pain wasn't felt by the ff developers. xulrunner is a great move toward a development platform but needs a seriuosly refactored xul to be first class. What would it take to attract Eclipse RCP developers and wxWindows developers?

Posted by: Dan Sickles at May 5, 2006 4:23 PM

Hallelujah!

I done a fair amount of work in XUL, and once you get over the initial learning curve it doesn't take long before problems become obvious. It definately has the feel of something cobbled together a little too quickly.

I've idly wondered if XUL should be made more HTML/CSS-like. It would lower the barrier to writing Mozilla UIs, and simplicity is good. Obviously (?) XUL and HTML have differing needs and goals, but reducing unneeded differences would be nice.

You can also spin that another way... With the rise of web services, what's lacking in HTML/CSS when creating UIs for those services?

Perhaps there is a common solution to both problems... [XBL?]

Posted by: Justin Dolske at May 5, 2006 4:38 PM

Yes!
I tried to develop an application in XUL about 2 years ago, and the learning curve was very steep. The starting concepts (hbox/vbox) were a great idea, but as soon as I tried to do something tricky it all fell down.
I'd love to see an iTunes-style editable treeview, with the option to connect it to a SQLite or external SQL database.
I'd love to see some decent calendar/time style widgets.
I'd love to see an EASY html form replacement, so developers could implement forms in XUL and if the browser supports XUL it would show this version.
I'd love to see some higher level objects for XMLHttpRequest - I know it's easy, but i think it can be made a lot higher level, for updating status widgets etc.
I'd love to see a local cache that websites can store code in - like a mini extension, so webapps are fast like local apps, but without the security privledges that an extension gets.

Cheers.

Posted by: Anko Painting at May 5, 2006 6:08 PM

I'm 100% behind improving XUL. It does have it's quirks, and when your not really comfortable with it, it's *extremely* annoying. On top of that, since there's less XUL dev's than CSS or HTML, the documentation on the web is much less (making searching the web for an answer less effective).

I'd love to see XUL mature.

Posted by: Robert Accettura at May 5, 2006 6:14 PM

Go for it! Don't hang on to poorly-planned things for too long - Microsoft did that and they ended up with WinME.

Posted by: ant at May 5, 2006 6:44 PM

I'm not a programmer but I have to agree with Robert Accettura.!!!

Otherwise it will be a mess... (it already is????)

Posted by: Albyxx at May 5, 2006 7:28 PM

You probably missed completely question about resources. Please name just one layout dev with CVS privileges who loves to work on XUL.

Posted by: bernd at May 5, 2006 8:50 PM

bernd - I'm thinking of a collaboration between new folk and existing XUL app developers. I'm trying not to think of things in terms of the resources we have now, but also the resources I'd like to see us again as a project (see my other posts on community development). I wonder if new folk tend to get sucked into non-XUL related projects because that's what "everyone else" is working on so it's easier to get help and guidance. I think as XUL app developers we may have to take on some of this work ourselves. But at the very least collaboration is required because you can't develop a toolkit in a vacuum.

Posted by: Ben at May 5, 2006 9:27 PM

rather than delay Firefox 3.0 with these changes.., something like this should be moved to 4.0+

Posted by: mdew at May 6, 2006 4:56 AM

There are different things you can do with XUL, some can get more public attraction like extensions, some can go where html can't like data intensive apps. XUL works wonders for all of them:

Remote XUL for the web
Enterprise apps for the intranet
Extensions for the browser
Stand-alone apps w/XULRunner

The old post/reload paradigm doesn't fit in data intensive apps. Many enterprise coders are playing with XUL and they need help.
I'd love to see tools like phpMyAdmin done in XUL, that would kick royal ass.
An email client like thunderbird for the web with free @firefox.com accounts would be the greatest marketing campaign ever. Ads revenue will follow.

XUL is good enough as it is, believe me. It needs improvement but no more than enthusiasm and a band of coders spreading love.

Posted by: GeorgeNava at May 6, 2006 6:37 AM

Well, what about XUL's performance?
Isn't it the reason for Firefox's high resource usage?

Posted by: b at May 6, 2006 7:33 AM

Amen. It always amazed me how evangelists outside of Mozilla (and even some Mozilla folks) claimed XUL provided an alternative to XAML. Sure, a bit of overconfidence is good for "sales" but that it shouldn't radiate into Mozilla's own developers, who know the truth: XUL, in its current shape, cannot stand against a platform (WinForms + XAML) designed for developers, developers, developers.

So let's make XUL something developers love, the way they love Qt and .NET.

Posted by: Ilya Konstantinov at May 6, 2006 2:33 PM

This reminds me that Aero Glass support in Vista would be nice for Gecko.

Posted by: kourge at May 6, 2006 4:04 PM

mdew, I don't think there's any way we can do major XUL work in the rendering engine for Gecko 1.9 at this point unless some sort of magic happens in terms of new developers appearing. So yeah, probably not in Firefox 3.0...

Posted by: Boris at May 6, 2006 5:38 PM

There's a lot of limitations with XUL as a server-side technology too. Drag and drop is all but impossible within a tree without a signed key. Is this security really necessary?

Posted by: Tony Perrie at May 6, 2006 10:02 PM

Great article Mr. Goodger. I can only say one word; Amen!

Posted by: hansen at May 7, 2006 1:24 AM

We need to factor XUL into a few different pieces and treat them differently. In particular, whatever aspects of XUL can be linked to other Web technology, should be.

Most of XUL's layout primitives should be factored out into a CSS extension that can be used by any markup language, especially HTML. This would be very useful for Web developers. There is great interest in doing this across browsers, we're really just waiting for someone to have time to work on a spec. This would deviate from existing XUL behaviour in some cases, mainly because we'd have much better integration between XUL box layout and CSS block layout.

Then there's the XUL widgets. Some features of XUL widgets can be extracted and generalized to any kind of content ... for example the cropping of XUL labels can be done using CSS3 text-overflow or some extension of that. Some XUL widgets we should move over to HTML to implement Web Forms 2, and XBL-bind them back to XUL. Other XUL widgets we will want to keep, but maybe implement differently. I am very interested in extending Gecko so that stuff like trees can be moved out of the C++ core and implemented in JS in toolkit.

Then there's XUL plumbing like overlays, keys, commands, stuff like that. Some of that may be generalizable to all documents. For example, XUL's mousethrough attribute would be generally useful. Other stuff only makes sense in "XUL documents".

One thing that would help a lot is eliminating the XUL-specific notion of "box objects". XUL elements should behave like other DOM elements and expose methods and properties directly ... that still leaves us with the duplication of DOM properties, DOM attributes and CSS properties, but at least that's no worse than regular Web programming.

A lot of the limitations in the widget code and the view system are going to go away in Gecko 1.9/FF 3.0. I assure you that if you hear me saying "this will be fixed in FF3", I mean it!! Many of them already went away early this year when I landed frame display lists. I have a patch that fixes the stack issue that hurts Safe Browsing, we just need to track down the performance regressions it induces. Apart from the cairo transition, Gecko 1.9 will also have frame display lists, major reflow refactoring, and major changes to widgets and the view system.

Frame display lists simplified XUL a bit, by removing some duplicated code and forcing e.g. mousethrough to work the same (rational) way in all situations. dbaron's reflow branch and the followup work it enables will likely do similar. One problem we have is that when we tweak XUL behaviour we'd like to document the changes and the new behaviour for current and new XUL developers, but there's no easy way to do that. We need a way for Gecko developers to be able to easily edit xulplanet.

Posted by: Robert O'Callahan at May 7, 2006 8:33 PM

Robert: Thanks for the insightful commentary. The other major part aside from XULDoc/layout stuff you mention is consistency in API, which we definitely don't have right now. I'm excited that the architectural improvements that are going on will allow us to remove more of the hacks and make the experience a lot better for developers.

Posted by: Ben Goodger at May 7, 2006 8:37 PM

One problem we have is that when we tweak XUL behaviour we'd like to document the changes and the new behaviour for current and new XUL developers, but there's no easy way to do that. We need a way for Gecko developers to be able to easily edit xulplanet.

Well, currently on the MDC newsgroup, they are discussing migrating the XUL Reference documentation over to the MDC, so that will solve this problem.

Posted by: James Napolitano at May 7, 2006 10:15 PM

As a developer,or I say spoilt developer,i always miss a good IDE for XUL based applications.I have not written a single word yet in XUL but i alwys wanted to and wanted to learn and do it fast.

What is need a good XUL IDE,tightly integrated with some framework so tht it could make packages and a good documentation along with lots of tutorials.

Posted by: Adnan Siddiqi at May 8, 2006 1:00 AM

I agree 100% with the need to improve XUL. My personal wish would be for more power to remote XUL. Remote XUL has all the wins of a web application (principally a single point of deployment), but with much of the power and speed of a desktop application.

It does have several problems, though:

1) Those damned security restrictions: I'd love to be able to easily whitelist within Firefox to allow Remote XUL on my intranet to run with the same privileges as an extension

2) No good localisation system: The local XUL solution works well, but there's no equivalent for remote XUL.

3) Low-level hooks: better control of printing output, access to serial ports, easy filesystem access, better (richer) clipboard support, etc. Yes there are security implications of allowing some of these things from remote XUL, but if a good whitelisting system can be implemented, or some other means of allowing approved remote applications to access low-level features and interfaces, it would open up a lot of possibilities.

4) Printing: Yes, I've mentioned it above, but it really is quite important. I blogged about some of the problems as a web developer and user a while back, but the problems are even larger for XUL where printing seems to be almost completely neglected.

5) Remote XULRunner: This might already be on the cards for XULRunner, but how about a version whose primary purpose is to act as a runtime for remote XUL? A cut-down installation with a single configuration file that the administrator can set to point at his server before installing it on everybody's desktops, or that prompts for a URL if such a file isn't present. It would make remote XUL an easier sell to companies that are still IE based; rather than them having to install another web browser, they're just installing a "runtime" or "framework" then everything else happens at the server.

6) firefox -chrome "http://XUL_URL...": One of the coolest tricks with Firefox is to add a shortcut to the desktop with a "-chrome" parameter so that it looks more like a desktop app. Don't lose this. In fact expand it (additional parameters for starting Venkman and the DOM Inspector as well, for example).

Anyway, whatever happens to XUL, don't forget that there are huge advantages to serving it remotely. One of the big advantages I see for XUL are the multiple deployment methods (remote, extension, XULRunner, local XUL files), but the advantage of reusable knowledge (and reusable code) goes away when one of these methods requires too much extra work, or adds too many limitations.

Posted by: Mark at May 8, 2006 1:39 AM

I completely agree with Adnan Siddigi! Remote XUL is so close to be the best environment to develop rich web application. It is a pity that in all these years nothing has been done to improve remote XUL while the competitors (Flex, XAML ...) are moving fast. I don't understand the reasons for this stagnation, but I fear that Remote XUL is not in the Mozilla developer's target. The Goodger's post seems to confirm my suspicious: he doesn't write a line about Remote XUL.

Posted by: faser at May 8, 2006 4:07 AM

I don't know much about XUL as far as coding but I would like to learn in the future just to code extensions for TBird so if fixing what's broken makes life easier for developers go for it! MS should have ditched legacy support starting with XP.

-PD

Posted by: P Dunn at May 8, 2006 10:46 AM

Regarding the very inconvenient but effective extension versioning system, as I understand what you've written, this is partly a result of the non-frozen API in XUL. If these changes you're talking about were to go ahead and the API were eventually stablised (despite the fact that it will probably break many thousands of XUL apps in the short term) would it mean that the extremely bad (from a user's point of view) extension versioning system could removed one day, and extensions could be made more forwards compatible?

Posted by: Lachlan Hunt at May 9, 2006 6:10 PM

Visitem:::: http://paredepublica.blogs.sapo.pt/

Posted by: António Cunha at May 13, 2006 12:34 PM

http://www.scoop.co.nz/news/parliament.html has a feed, but it isn't caught by the auto detector on 1.5.0.3

Posted by: G at May 16, 2006 8:06 PM

I was reviewing Remote XUL in Dec to develop an app with and decided against it. Mainly because it did not look like it had any direction. But I enjoyed working with it so much that im giving it another bash for an app to be completed in the next 3 weeks. It looks better, performs better and is easier to deploy than the Java/Swing app I had developed. Im taking the plunge and hoping like hell that it pays off. I would love to work on improving xul but as a crappy java developer where do i start :)

Posted by: Andrew at June 1, 2006 11:50 AM

"Break it" he says.

As the engineering lead of a first generation xulrunner application for 11 months now, I can easily agree with your gripes about xul's dirty little secrets.

But from the same viewpoint, your cavalier attitude towards the massive amount of legacy code out there scares the crap out of me.

It seems far more logical and economical to break your planned migration into a number of separate pieces. You can incrementally fix the layout engine and, at the same time, create a second xml namespace for your 2nd generation widget set.

While your argument that it would be senseless to have "two ways to do things" does make some sense, it seems to me that's the entire purpose of xml namespaces.

And this allows you to take the time you need to implement your new widget set at your own pace without leaving the rest of us out in the cold, waiting until we can come back inside.

Posted by: mig at June 2, 2006 12:54 AM

©1997-2006 Ben Goodger. All Rights Reserved.
Opinions expressed here are my own, and not those of any organization that I may be affiliated with.
Reload icon is © Stephen Horlander;
Firefox logo is by Jon Hicks, and is a trademark of The Mozilla Foundation.
GetFirefox buttons are from rakaz