We Keep Coding

Using print dialog from applet makes browser window unresponsive

I have a ten-year-old applet that wraps itself around the Crystal Reports Viewer applet in order to handle some custom features. It has worked satisfactorily, displaying and printing reports as designed. The web-app provides data selection, and then generates the HTML to invoke the applet with the correct parameters via an AJAX call.
I have one user (so far) who experiences the following problem: after generating the applet and viewing the reports, she prints the reports. Once the print dialog has appeared, even if it is cancelled, the following things no longer work:
the Close link which is supposed to clear out the generated applet HTML no longer works;
the navigation links to other pages no longer work: they dim appropriately when the mouse hovers over them, but the browser does not respond to clicking on them;
the window cannot be closed, whether
by clicking the X in the upper-right-hand corner,
by clicking on the system menu and selecting Close,
by right-clicking on the entry in the task bar and selecting Close, or
by trying to invoke the File/Exit menu item (I believe the File menu is disabled);
clicking on the window title-bar no longer makes it appear active.
In order to close the window, one has to start the Task Manager and end the iexplore process.
It may be that this is another occasion where the applet is retaining focus and it should not: similar bugs such as
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4838000
are reported as being folded into a bug I can no longer find in the Java bug base:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4918282
There are also reports of invisible applets retaining focus: it might be that the custom applet is invoking the original Crystal Reports applet in some way, but I didn't myself develop this code, just the wrapper that drives it.
I do not believe I have a case where a dialog of some sort is appearing behind the IE window; I should think that would occur on more than one system, and this appears to be unique to this user, but the system looks like one of our stock images.
There are also reports of printing locking up an IE window until printing is complete, where the solution is to put the printing into another thread. In my case, it is unnecessary to actually print: invoking the Print dialog and then cancelling it is enough to cause the buggy behavior.
I would like to understand what's going on here, and get things running for this user if possible. I'd appreciate any reports of similar experiences, or directions to look that I've so far missed.
Some version notes:
Win XP Pro: 5.1.2700 SP 2 Build 2600
IE: 7.0.5730.13
Java JRE: 1.6.0_31-b05
Printer: Imagistics 2500 USB printer (on the off chance)

Heavyweight components on Mac OS x in Java

I have an application which basically consists in a applet that runs on the browser.
I've been validating this application for Mac OS X and I came across with a focus issue that does not happen in Windows or Linux.
The problem occur, for example, everytime I use a JFileChooser to select a directory to save a file. After I select a directory and press 'ok' in the JFileChooser, if I'm running the application in Windows of Linux, the focus go back to the applet from where I opened the JFileChooser.
But on Mac OS X when I finish using the JFileChooser and I close it (or press ok) the focus does not go back to the applet. In that case I need to click somewhere inside the Applet to get the focus back there. This happens not only when I use JFileChooser but also every time I use a 'heavyweight' component.
I wonder if this is a know issue and we need to deal with it using for example requestFocus()? Any of you had problems with this before?

"Because the focus behavior of this method is platform-dependent, developers are strongly encouraged to use requestFocusInWindow when possible."
See answer here: java applet not grabbing focus in JRE 1.6.0_29 and up (OS X)
(I googled: "osx browser applet focus issues")

zombie java interpreter after launching applet prevents java console to reappear if relaunched

I have a java application that can be run as a JFrame or as an applet.
Launching the applet in the browser adds a new tab in the browser and also makes the Java Console appear. After I close both of them, I expect to be able to repeat this operation and see the Java Console reappear. It does not reappear, however I can reload my applet in the browser.
Everytime I have to kill this zombie java interpreter process launched by firefox.
/usr/lib/jvm/java-6-sun-1.6.0.26/jre/bin/java -D__jvm_launched=22906841394 -Xbootclasspath/a:/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/deploy.jar:/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/javaws.jar:/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/plugin.jar -Djava.class.path=/usr/lib/jvm/java-6-sun-1.6.0.26/jre/classes -Dsun.awt.warmup=true sun.plugin2.main.client.PluginMain write_pipe_name=/tmp/.com.sun.deploy.net.socket.1444.1704699298565364673.AF_UNIX
After killing the process, the Java Console will reappear. Also tried the repro steps with chromium, it's the same result except the zombie process' commandline is different.
Things to note:
When I close the browser tab containing the applet, the applet is in a normal state, waiting for the user to perform actions on the UI.
Closing the browser completely between applet relaunches will also fix the problem since the java process is a child of the browser process.
Anyone has an explanation or workaround? Thanks!

Anyone has an explanation or workaround?
For the work-around, test in the applet viewer. (The console is not relevant to production, unless the design is very flawed.)
As to the explanation, a browser will end the JRE/console when/if it feels like it. It is not up to the developer or applet to override that. I've noticed that FF will typically leave the JRE running for 30-60 seconds after leaving an applet page (judging by when the console vanishes).

It's not a zombie, by which I imagine you mean to imply something is going wrong; this is just how the Java plug-in has always worked. The first time it's needed, it starts up, and this may involve opening the console, depending on your settings. It will then continue to run until the browser shuts down. In other words, this is not a bug, but a feature.
Some browsers include a menu item for opening the Java console; you could use that to reopen it as needed, without killing or restarting anything.

Is there a way to detect browser closing in JApplet?

There are certain configuration files that the user should save before closing the browser. Is there a way to detect if the user is trying to close the browser and to warn them to first save the files?

You should define a public method inside your applet and invoke it using Javascript before the user closes a page:
window.onbeforeunload = document.YourApplet.YourMethod(event);
where YourApplet is your applet's name attribute: <applet name="YourApplet" ...
and YourMethod is the method you defined in your applet.

You can use javascript to detect this. And you can invoke applet methods from javascript.
So you should define a javascript onunload handler which invokes your applet's close method.

Generally the PlugIn will try to stop the applet once the browser window (or just tab) closes or navigates elsewhere.
IIRC, you used to get 20 seconds to do your clear up before the PlugIn started getting medieval. I believe if there are no other applets sharing the JVM, the process will now get killed if you don't stop.
So, you really don't want to be hanging around attempting to show annoying save dialogs. I would go so far as to say, you don't want annoying save dialogs. So just do the saves quietly. Add a "you didn't save, do you want to restore these changes" thing (like the re-open windows dialogette beneath the toolbar in Chrome) when restarting. For extra marks, log deltas periodically in the background, so that even in the case of abrupt termination or network failure the data can be restored.

Can I make my Applet end more gracefully?

I have a JApplet which I contains various Swing components. It also starts a couple of extra threads in the init() and generally does other pretty standard applet-y things.
If I close the browser window containing the Applet, the JRE doesn't die (the icon remains in the system tray) until all the browser's windows have been closed (ie the browser has completely ended and disappears from the task manager)
Is this the expected behaviour or should the JRE end when the browser window enclosing the Applet closes?
I have a destroy() method, but (at present) it only stops the extra threads I started in the init() method. Should I be doing more in here maybe? Are there any other best-practises I should be following?
If you'd like any more info, please let me know in the comments.
:-)

I believe the JRE is loaded as a plugin to the browser, and the icon is supposed to remain in the system tray until the browser ends.
The reasoning behind this is that if you load one applet, leaving the JRE running will accelerate future applets' loading times.