Window chrome is treated like HTML content: it's parsed and built and handled by the same layout engine using the same rules. The resulting boons to design and usability are well discussed. Several problems follow from this approach, described in this section and others.

A window's chrome cannot be loaded immediately or synchronously. This causes difficulties in, for instance, deciding on the return value from JavaScript's window.open call, since the content webshell is created asynchronously.

Without explicit protection from each other, Java, JavaScript and plugins in the content and chrome webshells can access each other. See also Security.

Solutions

window.open should create and return a content webshell immediately. This webshell must be cached and later substituted for the actual main content webshell when the proper placement for that object is discovered in the chrome description. The first part of this two-step solution has been implemented at time of writing.

Timing of EndDocumentLoad

There is processing to be done once a document has been loaded. This is code normally found in places like onload event handlers. For chrome documents, widgets and command structures must be initialized and hooked up. HTML documents have varied requirements unique to their documents.

This processing is triggered by the receipt of an "on connections complete" event. Separate events should be received for the chrome and content. There is some debate about the proper timing of these events. In the simple case of a browser window with one content area, it would obviously be preferable for the chrome final initialization to happen without first waiting for the HTML content to load. Mailnews, on the other hand, have subchrome documents they'd like initialized before the superchrome is initialized. Before implementing an initialization model, we must first decide which is best.

Solutions

Webshells propagate the EndDocumentLoad event to their containers, so it seems the question of order can be solved by finishing loading the outermost chrome first, and making its handlers able to put off handling of as-yet incomplete subchrome. They'll be notified again when the subchrome has loaded.

As for the more interesting issue, the content webshell should be initially loaded empty; a load of its contents being fired during handling of the chrome's EndDocumentLoad event. This neatly separates the loading of the chrome and content documents, and ensures correct loading order.

I believe no one is working on this issue at time of writing, though the entire handling of a XUL document's EndDocumentLoad event is currently being brought into line with Gecko's general model currently implemented for XML and HTML documents.

Chrome contains content

The outermost webshell (JavaScript "window") of a browser window contains chrome, not HTML content. Loading content into the topmost webshell is an operation which has been taken by the scripting model in all previous browsers to mean replacing the entire contents of a window. In Mozilla, it means replacing the chrome.

Ambiguity in the meaning of "content"

Historical APIs expect a browser window to contain exactly one content area. window.open takes an URL for this content as its single most important parameter. In the new world, a browser window can have no content at all (though arguably it could hardly be called a browser then), or several.

Chrome content ID registry

Though the exact contents of a browser window's chrome is highly variable, legacy APIs and ease of use demand an interface whereby certain well-known features expected to be in the chrome of a usable browser window can be accessed. A script can request a window without a location bar, for instance. And the generic window loading code to which we aspire has a need to know whether the XUL content it's handed happens to contain a location bar.

Solutions

Part of Mozilla's responsibility in creating XUL will need to be the definition and (at least in the short term) maintenance of a registry of IDs for well-known chrome elements. Application components can query the chrome for features using these IDs when locating the appropriate widget to carry out UI operations.

The browser window will need well-known IDs only for its well-known scriptable chrome features: toolbar, location, status and menubar. It may never require an effort more ambitious than the simple documentation of IDs for these four widgets. But other application interfaces may have greater requirements, and plugin implementors may concern themselves with these details. It would be useful to support a registry for these things.

JavaScript backwards compatibility

Historical JavaScript allowed chrome features to be specified and queried through a list of flags. For instance, the personal toolbar and location field were controllable this way, as were widgets not strictly part of the chrome content, such as scrollbars and the resize widget. These chrome elements are now completely specified in the XUL used to open the window. Not only is it unclear how to specify the chrome corresponding to these programmatic flags (separate XUL files for the 128 possible combinations seems like the wrong way, and probably causes problems with the shared DOM), but it is also unclear how to ask the chrome, once built, which chrome features it contains. See chrome content ID registry for a likely solution.

window.open is a particular nuisance: it takes an URL describing the browser content as its single content parameter. We must continue to support this syntax, while we need the ability to specify first the chrome URL, and then one or more content URLs.

Threading

The whole issue of multiple simultaneous windows, some of them alerts in response to netlib requests, in a single-threaded environment is such a musclebound, lion-eating snake it can hardly be described.

One associated problem follows from our single-threaded, mostly non-reentrant UI. Layout will attempt to completely finish drawing one window before progressing to another. This implies usability annoyances with multiple main ("browser") windows, and far greater problems from using the same engine to draw dialogs and alerts which may arise during browser window layout.

Solutions

Layout will be made reentrant, which will make layout-driven alert dialogs not impossible.

Modal Dialogs

Dialogs which stop execution of the calling function until the user interaction with the dialog has been completed pose special problems with our application architecture. Stopping a function while running the dialog poses some problem. A dialog must operate on its own thread, or the primordial thread, on Windows, at least. This is a problem in Mozilla since though the UI itself is single-threaded, the entire application is not.

Solutions

Stopping a function's execution while a modal dialog runs should be possible using captive event loops. This should work nicely on Windows and Macintosh, since the OS on these platforms generally codes modal dialogs coded just this way. Whether this approach will work on unices is currently under investigation.

Dialog Data I/O

Moving data into and out of dialogs turns out to be problematic, and several solutions are being implemented. This may itself be a problem. By dialog I/O, we mean setting the initial control values at dialog creation and querying the same control settings during dialog dismissal. Modeless dialogs are not a real concern: they are just windows and already need to have some way to reflect control changes in the larger application by their nature as a live palette of controls.

Modal dialogs require a convenient point to initialize control settings before the dialog is displayed, and to notify the caller of their control settings after the window has been dismissed. We are considering several possibilities.

Solutions

JavaScript onload handlers and event handlers for the dismissal buttons are convenient points to move data in and out of the window at the appropriate times. The issue of where to move the data from or to remains. window.opener, the parent window, will often be the right choice. AppCores or (soon) scriptable services; drop-off points into the C++ code, are also good candidates. The C++ version of JavaScript event handlers is DOM event listeners.

A second solution for data input under consideration is encoding of data at the end of the URL for the dialog contents in much the same way as CGI programs expect data from method=GET forms. Any collision between this re-use of the same data passing mechanism, should such a dialog itself be the result of CGI output, would be expected to be resolved by both the CGI program and the dialog initialization code each using unique parameter names.

Another JavaScript solution for data I/O under consideration is the addition of a new parameter to the window.open call -- probably added to a new window.opendialog call since the last parameter to window.open is already a variable-value placeholder. This new parameter would be an array of variant values which the caller and dialog are free to interpret as they like.

Security

I believe it can be safely stated even by holders of the most liberal model of content and chrome interaction that the chrome requires some protection from the content. The chrome and content webshells require insulation from each other not provided by the default JavaScript model.

Shared, persistent chrome DOM

Our implementation of XUL content shares a single in-memory DOM between all windows with content from the same URL, and changes to this DOM will be persistent, or at least persistible. This is just a point to keep in mind when designing implementations. The act of making changes to a chrome DOM may have unexpected side effects.

Embedded Gecko

Gecko has needs for presenting UI outside its immediate content area, as alerts and dialogs, particularly for questions posed by netlib. As an applications team, we have been designing these dialogs to be fulfilled by application components, assuming the runtime presence of features not likely to be present in an embedded implementation. XUL for window content description and appshells for running the windows come to mind.

Applications believe this is the right path for them, though it leaves Gecko without a packaged solution. This is an issue to be resolved.