Personal tools
You are here: Home / cmgui / Zinc / Using Windows and Dialogs with zinc applications

Using Windows and Dialogs with zinc applications


When writing an application it is often useful to be able to open a second window to show the user extra information. For example when running cmgui it is possible to open a scene viewer window to get information about the scene and its setting.

Applications also often use dialogs (a special kind of window) in order to get some sort of response from a user. An example is the file open dialog. If you want to open a file in firefox, you click on the file open menu and a dialog pops up which allows you to pick the file you want.

Windows vs Dialogs

Recall a dialog is used when you want some sort of response from a user. A dialog is a special kind of window which has added functionality which nicely supports passing objects/variables from the opening window to the dialog and getting information back. You can also pass information backwards and forwards between the opening window and a normal window but this can only be done via the window.opener property. In general if you want some sort of response from a user it is cleaner and easier to use a dialog. Dialogs can also be made modal, which means the user must respond before they can return to use the original window.

A disadvantage of using windows instead of dialogs is that many users have settings enabled that prevent their browser displaying popup windows. This means users will have to enable popups (at least for your domain name) in order to use a mozCmgui application which relies on opening windows.

Opening windows and dialogs from XUL code

There are several issues to consider when writing XUL code to open a window or dialog. The first thing you must be aware of is whether your XUL code is running as chrome or not because non chrome XUL can not open dialogs. Below is a brief explanation of what chrome XUL is. See the XUL tutorial for a full explation of chrome:

Chrome XUL is treated as part of the mozilla source and hence is trusted. It is allowed to do far more useful things than non chrome code including accessing your file system to read and create files. Non chrome XUL has much more limited access, to make it impossible for non trusted code to access your files and do nasty things.

Code becomes chrome by either adding it directly into the chrome directory in your firefox installation (and configuring a few things) or by installing an extension. See Installing code as Chrome for more information. You can access chrome XUL files using the chrome:// protocol or by clinking on a link to a chrome xul file. If you are just opening up a normal XUL file using your browser and the http:// protocol your XUL is NOT chrome. A standard mozCmgui application like the ecg_lab is therefore NOT chrome XUL. (Whereas the mozCmgui extension itself does contain chrome XUL).

Remember non chrome XUL can not open dialogs. As of Firefox the only way XUL code can use the window.openDialog command is if it is running as chrome. I wanted the mozCmgui digitiser applicaton to open a dialog to select some options. Unfortunately as it was non chrome this was not possible. I tried to get around this by adding javascript code to open a dialog into the mozCmgui extension and then including the javascript file into the digitiser. Unfortunately when you use a src tag to include javascript in a non chrome .xul file the javascript becomes non chrome. The .xul file itself must be installed as chrome if you want to call the window.Dialog command.

Fortunately non chrome XUL can open windows so you can at least create a normal window. In some situations this helps a lot. If you must use a dialog then your options are to make the entire application into an extension (so your .xul and .js files run as chrome) or create an XPCOM object that will deal with the dialog. For info on how to create an XPCOM object see Writing XPCOM components for zinc.

Using the window.opener property from a widow/dialog that is chrome

Using the window.opener property to communicate with the opener is very limited. If the opener is chrome you can only access standard mozilla functionality through the window.opener property (ie you can not call a routine you have written in javascript associated with the opener). If you want to access more than the generic functionality this can be done using the window.opener.wrappedJSObject trick but this may be a bad idea for security reasons.

Using window.opener.wrappedJSObject allows access to your own javascript but it also means someone could potentially write a non chrome script that opens your window and then gets its own code execute with chrome priveleges.

If you want to use the wrappedJSObject you should first check that it is safe to do so by checking that the opening window has chrome priveles. This can be done as follows:

function printMessageIfSafe()
  // we should check to see if the opener has chrome priveleges before
  // using wrappedJSObject to access javascript functions
  var locationURL = window.opener.location.href;
  var win = window.window;
  if(window.opener.location.href.substring(0,6)=="chrome") {

    // need some way of returning the focus to the original window
    // unfortunately window.opener.focus does not work (bug in mozilla)