How to simulate a modal dialog inside an applet?

Question

In 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) { } } 

In most browsers this works fine. However, in Opera and Safari for Windows, I came across the following big unpleasant 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 creating fake modal dialogs in these browsers?

Answer 1

This permission should be granted if you do not have a strange implementation (Sun PlugIn provides it with 1.2.2, IIRC). What versions are we talking about?

This is probably not the best sending cycle.

You should isVisible call isVisible with EDT.

Modal interfaces are usually unpleasant.

What is wrong with modal dialogue?

Answer 2

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

Answer 3

The reason for the problem with Opera may be that Opera has its own java.policy file called opera.policy (in the Opera_installation_directory \ classes folder). Although in my Opera installation I could not see any permissions that were not granted in Opera, but granted in the default java.policy file.

Answer 4

You do not need to sign an applet for this to work?

Signing applet

By letting the applet do all this, it's a digital signature. In essence, the signatory says: "This applet is safe to use, and if you trust me, you can trust this applet, because thanks to my subscription you can be sure that since I signed it." Then the user will be asked if she wants to trust the subscriber (usually in a small dialog box), and if she does, the applet can act with full privileges. If trust is denied, the applet continues to run inside the sandbox with limited privileges.

The decision about whether to trust applets should be made very wisely, because a trusted applet has the same privileges as a locally running application: it can read and delete files, and also transfer data over the network.

A more detailed explanation of applet security model can be found here. This includes a complete list of applet restrictions.

For an applet signature and links to additional information, read this and especially this. Internet Explorer (and MS JVM) are a little 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 a privileged code:

AccessController.doPrivileged (new PrivilegedAction () {public Object run () {// perform a safe operation here return null;}});

JavaDoc: java.security.AccessController

Policy files

An alternative way to provide additional applet features is to use policy files, which Sun has an introductory article on, and another specifically for applets. Using policies, you can manage a smaller-scale way that gives privileges to provide an applet. For example, it becomes possible to give applets access to the local file system, but not to any other features that they have been denied. Here is an example of this.

The disadvantage of using policy files is that they are located in the local file system, so users must make changes to the file, which is usually out of sight, and the content of which is not trivial to understand.

The following example shows how to undo most applet restrictions. Any permissions can be made more specific, for example. FilePermission can only be set for selected files and is read-only. Javadocs for each Permission class explain in detail what is possible. It is good practice to use the most limited settings. 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