How do I simulate a modal dialog from within an Ap

问题:

On setVisible(true), I call the following code to start a modal dialog:

private synchronized void startModal () {
  try {
    if (SwingUtilities.isEventDispatchThread()) {
      EventQueue theQueue = getToolkit().getSystemEventQueue();
      while (isVisible()) {
        AWTEvent event = theQueue.getNextEvent();
        Object source = event.getSource();
        if (event instanceof ActiveEvent) {
          ((ActiveEvent) event).dispatch();
        } else if (source instanceof Component) {
          ((Component) source).dispatchEvent(event);
        } else if (source instanceof MenuComponent) {
          ((MenuComponent) source).dispatchEvent(event);
        } else {
          System.err.println("Unable to dispatch: " + event);
        }
      }
    } else {
      while (isVisible()) {
        wait();
      }
    }
  } catch (InterruptedException ignored) { }
}

This works just great in most browsers. However, in Opera and Safari for Windows, I am confronted with the following big-nasty-exception:

java.security.AccessControlException: access denied (java.awt.AWTPermission accessEventQueue)
    at java.security.AccessControlContext.checkPermission(Unknown Source)
    at java.security.AccessController.checkPermission(Unknown Source)
    at java.lang.SecurityManager.checkPermission(Unknown Source)
    at java.lang.SecurityManager.checkAwtEventQueueAccess(Unknown Source)
    at java.awt.Toolkit.getSystemEventQueue(Unknown Source)

Is there a workaround for generating fake-modal dialogs in these browsers?

回答1:

That permission should be granted unless you have a strange implementation (Sun PlugIn has been granting it since 1.2.2, IIRC). Which versions are we talking about?

That probably isn't the best dispatch loop.

You probably should call isVisible off the EDT.

Modal interfaces are generally nasty.

What's wrong with a modal dialog?

回答2:

If I might offer a different approach that could work, instead of intercepting the events in the event thread, you could use the glass pane to block all input requests.

回答3:

Don't you need to sign your applet in order this to work?

Signing an applet

The way to allow an applet to do all those things is to digitally sign it. In effect the signer says "This applet is safe to use, and if you trust me, you can trust this applet, because through my signature you can be assured that it has not been tampered with since I signed it." The user will then be asked if she wants to trust the signer (usually in a little dialog box), and if she does, the applet can proceed with full privileges. If the trust is denied, the applet continues to run inside the sandbox with limited privileges.

The decision of whether to trust an applet should be made very judiciously, because a trusted applet has the same privileges a locally started application would have: It can read and delete files, and transmit data over the network.

A more thorough explanation of the applet security model can be found here. That includes a full list of the applet restrictions.

For an introduction to applet signing and links to more information read this and especially this. Internet Explorer (and the MS JVM) are a bit non-standard; read this for an overview of what to do.

If, even after signing the applet, you still get a SecurityException, try running the code as privileged code:

AccessController.doPrivileged(new PrivilegedAction() { public Object run() { // perform the security-sensitive operation here return null; } });

JavaDoc:java.security.AccessController

Policy files

An alternative way to grant an applet additional capabilities is the use of Policy files, about which Sun has an introductory article, and another one here specifically for applets. Using policies it is possible to control in a more fine-grained way which privileges to grant an applet. E.g., it becomes possible to grant applets access to the local file system, but not any of the other capabilities they are denied. Here is an example of that.

The drawback to using policy files is that they reside on the local file system, so users must make changes to a file that is normally out of their sight, and the contents of which are not trivial to understand.

The following example shows how to revoke most of an applets restrictions. Any of the permissions can be made more specific, e.g. FilePermission can be given for only selected files, and with read-only access. The javadocs for each Permission class explain in detail what's possible. It is good practice to use the most restricted setting possible. RuntimePermission in particular can be used to create ClassLoaders and SecurityManagers, which can circumvent even more applet restrictions.

 grant codeBase "http://geosim.cs.vt.edu/geosim/-" {
   permission java.io.FilePermission "<<ALL FILES>>", "read, write, execute, delete";
   permission java.net.SocketPermission "*", "accept, connect, listen, resolve";
   permission java.util.PropertyPermission "*", "read, write";
   permission java.lang.RuntimePermission "*";
   permission java.awt.AWTPermission "showWindowWithoutWarningBanner";
 };

Javadocs

JavaDoc:java.awt.AWTPermission JavaDoc:java.io.FilePermission JavaDoc:java.lang.RuntimePermission JavaDoc:java.net.SocketPermission JavaDoc:java.util.PropertyPermission

回答4:

The reason of having a problem with Opera might be that Opera has its own java.policy file named as opera.policy (under Opera_installation_directory\classes folder). Though, in my Opera installation, I couldn't see any permission that is not granted in Opera but granted in the default java.policy file.