XUL:Windows

Introduction

XUL gives you enough rope to hang yourself with its myriad of window open options for sizing, resizability, features etc. What seems intuitive seldom works as you really want across all platforms.

Sizing

There are several ways to size a window:

1. window.open("foo.xul", "", "width=400,height=500");
2. <window width="400" height="500" ...>
3. <window style="width: 400px; height: 500px;" ...>
4. <window id="foo" ...> #foo { width: 400px; height: 500px; }
5. window.sizeToContent();

Using width/height attributes and pixels is the only way to go if you want a resizable window whose width and height persists between sessions, since persist only works on attributes and width/height are updated after each resize. (Aside from wacky hand-rolled solutions that are probably not recommended).

Few places in Firefox XUL code use the width/height window features in open/openDialog.

Using an inline style attribute on the window element seems to be the only way to use ems, which is the only font size safe way of sizing a dialog box.

Using a style rule located in a separate style sheet to size a window doesn't seem to work at all.

sizeToContent has very specific use cases.

We need documentation explaining how windows are sized intrinsically, what the fallbacks are, identify what fallbacks are broken and fix them to do something sane, etc. And then a set of best practices. Intuitively, any of the above should always work, but some are better for certain circumstances and that should be called out and perhaps even enforced by the API (e.g. sizing in ems for <dialog>s, using width/height attributes for <window>s based on observed use).

Other Features: Modality, Resizability, Toolbars etc

Very often you end up writing XUL on Windows or Linux and you end up with a strange title-bar free window on Mac, one without a close button, etc or something else major that prevents the window from working. It seems that open/openDialog and the Window Watcher give you a per-feature way to instantiate a window, but really what you want in most situations is to open a toplevel window, or a dialog. Convenience methods to do that and get the job done right on Mac and other platforms would help prevent a lot of small but annoying bugs.

Resizers

Resizable windows should have resizer markers in their bottom right corners. App developers should not need to do this themselves. The marker should not steal space from the content within the window.

Preferences Windows

Preferences windows have no close button on MacOS X so getting the features right is more important. The canonical way, per utilityOverlay.js is:

function showPreferences(paneID) {

 var instantApply = getBoolPref("browser.preferences.instantApply", false);
 var features = "chrome,titlebar,toolbar,centerscreen" + (instantApply ? ",dialog=no" : ",modal");
 var wm = Components.classes["@mozilla.org/appshell/window-mediator;1"]
                    .getService(Components.interfaces.nsIWindowMediator);
 var win = wm.getMostRecentWindow("Browser:Preferences");
 if (win) {
   win.focus();
   if (paneID) {
     var pane = win.document.getElementById(paneID);
     win.document.documentElement.showPane(pane);
   }
 }
 else
   openDialog("chrome://browser/content/preferences/preferences.xul",
              "Preferences", features, paneID);

}

This needs to be rolled up somehow into a clean API.