XUL:Common Problems

Here are some things that many XUL developers tend to have a difficult time understanding. These are the kinds of things that documentation doesn't seem to solve.

Comments NeilDeakin

Chrome

The term

People have difficult time understanding chrome. For instance, it is common to assume that files placed in the chrome directory have added privileges. Or, that the 'navigator/content' part refers to an actual directory. The problem, I think, is partially caused by overuse of the word chrome. Consider:

chrome

the browser UI around the web page

chrome URLs

the chrome protocol which is the only way to get privileges

chrome directory

the directory where the apps put their UI files

chrome command line argument

start and open a file in a top level window

chrome argument to window.open

opens a new window top level

chrome.rdf

the chrome registry, in install directory and in profile

It seems to me that at least some of these uses could be changed, or deprecated.

Chrome registration

In addition, there's the fact that there is no way of knowing whether your newly created chrome application is set up right and you haven't messed up your RDF somewhere.

This problem is of concern since registering a chrome application is the first thing developers need to do. If this is too hard, they become discouraged.

This has become much better after bsmedberg's changes to chrome registration, and for example getting started with writing extensions should be quite easy because there are quick-start guides and downloads: [1]. We should provide such stubs for xulrunner apps too. --Nickolay 11:09, 11 Feb 2006 (PST)

Trees

Some common issues about trees:

• an assumption that there are always DOM nodes for the tree rows. For instance, I've seen people implement their own nsITreeView and then wonder where the DOM nodes are.
• developers try to use the style attribute.
• desire to put arbitrary content into trees.

Trees are one of the parts of XUL that has been improved recently.

I am of the opinion that trees don't really need to support any kind of content, apart from text and a few other things that it already supports (images, checkboxes, progressmeters). The only thing missing is UI to edit the tree cells. I had created a demo of this, but a view issue with the caret rendering prevented it from working perfectly. For editing, it just needs to be able to support placing a textbox or menulist in a cell temporarily.

Some people have tried to use the tree to create a spreadsheet like UI. For this, I think the real answer is to use a grid instead. One could imagine creating a more specialized widget for this.

Templates

XUL:Xul Templates are difficult to understand, but I think everyone knows that already. Mainly since they don't offer any guidance when the user went wrong. Some of this can be solved, for instance, by detecting template syntax errors or reporting RDF parse errors. But many problems are logic errors which would only be detectable by producing some kind of log of what was happening.

I've managed to convince myself that templates do work, and they do a lot more than most people realize. Maybe I should finally get around to writing that How Templates Work guide I've been meaning to write for a while now.

-> http://developer.mozilla.org/en/docs/XUL:Template_Guide

Element Interfaces

One issue I had when creating the element reference was that a number of elements claim to support some interface in their XBL implementation but then don't implement all of its methods. These are just bugs, but we should fix them.