XULMaker Project

Issues

Mozilla Issues

The following issues are issues affecting the development of XULMaker but resolution can only happen by changes in Mozilla. (Some of these issues may go away if and when we learn how to use Mozilla correctly in these cases.)

<arrowscrollbox> not working in horizontal orientation

Containing a set of toolbarbuttons in a <arrowscrollbox>doesn't work as expected. Although it was meant to work for a vertical list of buttons, it makes sense that it should work as well for a horizontal toolbar. A kludge solution is to add the attribute orient="horizontal" to the <arrowscrollbox>. This fixes the problem for a horizontal toolbar but the scrollbar buttons are still oriented for a vertical scroll even if the toolbar displays horizontally.

<window> debug attribute is not dynamic

When we set/remove the debug attribute on the <window> element the corresponding display does not immediately reflect this change.

(For more information on this feature see XULPlanet's "Main XUL Tutorial - Chapter 11. Specialized Window Types - Features of a Window - Debugging a Window".)

Serialization

Serialization has a number of issues.

Serialization strips off attributes

Serialization strips the <window> element, and only the <window> element, of all its attributes - particularly the xmlns (namespace) and debug attributes.

Serialization strips all elements of all event attributes, e.g. "onclick".

Serialization takes on a namespace where none is defined

When we serialize our XUL document to text all XUL elements are given a "a0" namespace and the <window> element includes the namespace attribute for this - even though a "blank" namespace is given in the original XUL document.

Serialization doesn't handle whitespace correctly

I'm not sure that it handles whitespace correctly.

XULMaker Issues

Save File on Dirty Flag

Currently when you do a File | New , a File | Open , a File | Close , or a File | Exit , we do so without saving the current document. We need to set a dirty flag whenever a change has occured and check this for each of these commands.

Browser View

We currently can't interactively display the XUL document in the browser. Currently you are required to save the XUL document so that the browser is able to view it by reading the file.

The <browser> element can display either HTML or XML/XUL code - using the "src" attribute in the <browser> element, or by using loadURI() method in script. It can also display HTML code - using a document.write(). But it is NOT able to display XML/XUL code - using a document.write(). The documentType by default is "text/html" and I have not yet found a way of being able to change this. (There is extensive scaffolding code in place in trying to solve this issue.)

Tree and <treeitem> Selection

This has been a real struggle. It's been difficult to dynamically make a selection in a tree. (see ElementTree.selectElement() in ElementExplorer.js.) There doesn't seem to be an easy way of doing this. We need to do this as a response to selecting the "active" element in some other view.

Currently we identify the selected item using tree.view.getCellText() and set the currentIndex by calling tree.view.selection.select(index). (How easy was that to figure out!) This is a kludge, however. It doesn't identify the "active" element if it is hidden in the tree and then we open the tree and make it visible.

Code View - Serialization

The code view does not properly represent the XUL document. Unfortunately, what you see in the code view is also what actually gets saved in a file when you save. The following are some of the known issues.

(* See Mozilla Issues - Serialization)

Code View - Parsing

The "update model" button doesn't do anything at this point. The code behind this is in place but doesn't work just yet.

XML Schema

XML Schema is used to define all XUL elements and attributes. Most of the code to do this is in place. The code currently can only read an XML Schema file with an absolute address. We also haven't been able to get evaluate() to work. In the meantime, we have turned off the code. We have left the completion of this for the next version - 0.50

Immutable Element Id

You can change the id of an element in the Attributes Inspector but that then corrupts the application. Any changes to an element's id needs to be communicated to all views containing the XUL document

Tree View Open States

The open/close states of each tree item's grippy isn't remembered and re-instated with each refresh.

(The ElementTree::update() method needs to re-instate the open states. The remembering code for this is there but the re-instate code has become broken).

Cosmetics

The following are some cosmetic issues which have not yet been resolved