Modal Dialog Bug Demonstration

JDK 1.0 based browsers do not understand modal dialogs. Some JDK 1.1 browsers such as IE on Mac still have problems with modal dialog behavior.

Details On The Modal Dialog Bug

One of the primary uses of dialogs consists of asking the user for some information before continuing. Setting the modal flag to true tells the application that it cannot continue the thread of execution until the dialog has been answered.

Unfortunately, this behavior is highly inconsistent across platforms and browsers. There are really two different buggy behaviors of modal dialogs.

The first bug which is demonstrated by the first applet below, is that some browsers allow the applet to continue doing things like accept GUI events even after the dialog is on the screen.

This can result in multiple dialogs if the user starts clicking around and effectively does not force the user to do anything. This is the case even in Netscape 4 (4.05).

The first applet allows you to click a button which should spawn a dialog. The applet will then immediately attempt to get the result. With proper dialog behavior, the thread of execution stops until the user has clicked OK or Cancel. Then, the applet gets the result and prints it to the Java Console and sets the textfield label.

On well-behaved browsers, the textfield label will appear OK. However, there are some interesting side effects of browsers that appear to work, but are not entirely correct.

For example, Netscape 4.05 allows the main applet button to be clicked many times resulting in many dialog windows.

The thread of execution is stoped in the event handler in 4.05 but it appears that multiple incarnations of the event handler thread are at work, because if you click OK on one dialog, the results are given back to the browser. And subsequent dialogs can be clicked as well.

The way the first applet is coded though, there is only one handle (global to the applet) for the dialog. This means that the last dialog that is created actually wins out since its state is the one that is polled by all the event handler threads that have been spawned.

This is definately weird behavior. It's like the dialog is Half Modal.

Dialogs opened from within a java applet spawned Frame() fare much better in understanding modality. But JDK 1.0 based Netscape and IE 4 on Mac and Solaris continue their thread of execution even after the dialog is brought up. Thus, if you are relying on data appearing after the dialog's show() returns, then your application will simply not work on these platforms.

In the second applet (and the first), the state of the dialog box result is printed to the console and to the label. This reveals that different browsers treat this problem differently.

For example, Netscape 3 on Mac and Windows gives a well-behaved and expected "null" as the result when the thread of execution stays effective.

But Netscape 3 on Solaris actually throws an exception. It calls the state a "modal deadlock".

Modal Dialog Workaround

Put simply, there is no direct workaround. But you can use alternative coding methods to provide a similar effect.

To simulate the need to perform some action immediately after the dialog box has ended, simply use a callback.

The simplest callback involves coding a public method in your calling class which does what you want it to do and gets the information as part of its parameters. Then, pass your calling class by reference to the dialog when it is constructed.

Finally, code the dialog so that when the information is collected, it calls the public method on the calling class that was passed by reference.

This alternative coding style is demonstrated in the last applet.

Note: You may think it is messy design to force the dialog box to know about the class that it is serving and you would probably be correct.

If you are concerned with the coupling of the dialog to a specific class, use an intermediate interface with the public callback method defined instead. That way, any object that implements the interface can use the dialog.

Of course, this is still messier than simply having one class know about a public method in the dialog, but at least it works.

The non-interface simple callback is demonstrated in the last applet on this page.

References

CORE WEB PROGRAMMING by Marty Hall. I use his getParent() routine in the applet to get the applet's parent recursively until it finally encounters one that is an instance of frame. Marty Hall also outlines the various JDK problems with using Dialogs.

Applet Demonstrating Modal Dialog Failure From Applet

View The Source To DialogBug.java
View The Source To DialogBugDialog.java

Applet Demonstrating Modal Dialog From Frame Bug

View The Source To DialogFrameBug.java
View The Source To DialogFrameBugFrame.java
View The Source To DialogFrameBugDialog.java

Applet Demonstrating Modal Dialog Workaround

View The Source To DialogFix.java
View The Source To DialogFixDialog.java