SUGGESTED FIX

On more investigation and discussions with PDE, it has been decided to backport fix for 6491273 to 5.0 with any necessary changes specific to 5.0 codebase.
                                     

EVALUATION

We need to honour the frame owner passed in Toolkit.getPrintJob(...) call which is not done.   The fix for 6491273 in 7.0 addresses this issue and needs to be backported to 5.0
                                     

EVALUATION

I could reproduce the problem even when IE is not in the maximized mode. It seems to be a race condition here.

We follow the below logic in identifying the parent for a native print dialog when run on a browser:

1. Get the current active window just before print dialog is invoked and make it as the parent of the print dialog
2. If the active window is null, we get the last active embeddedframe before print dialog was invoked and assign it as the parent of the print dialog (Fix for 6522028)
3. If the last active embeddedframe is also null, we just iterate through a list of available embeddedframes and make the first one as the parent of the print dialog.

In the customer's app, the current active window as in step 1 is returned as a CasaWaitDialog (customer's awt dialog) and hence we set it as the parent of the native dialog. So far so good. But here comes the problem. The CasaWaitDialog is immediately disposed just when the print dialog is about to popup or has popped up.
Note that in awt, when a parent frame/dialog is disposed or hidden, all the child frame/dialog are also disposed and hidden respectively. Hence in this case, the print dialog gets disposed/hidden as soon as it pops up.

The user may wonder as to why it doesn't happen all the time and happens randomly. We get the current active window in our jdk code (WPrinterJob.java) by calling KBFM.getCurrentKeyboardFocusManager().getActiveWindow() and sometimes it's returned as the IExplorerEmbeddedFrame and sometimes as the CasaWaitDialog since it sometimes takes a while for it to get disposed.  As long as current active window is returned as IExplorerEmbeddedFrame one would always see the print dialog popping up as it's a visible embeddedframe on the browser and will be there throughout the lifecycle of the applet. This timing issue makes the bug appear randomly.
                                     

SUGGESTED FIX

Based on the evaluation, I think the current safer way would be to make the last active embedded frame as the parent of the print dialog.

i.e 
File: sun/awt/windows/WPrinterJob.java
Method: public Window getParentFrame()

Replace
 if (isPluginContext() && w != null ) {

with

 if (isPluginContext() && w != null  && w instanceof EmbeddedFrame) {
                                     

EVALUATION

This is regression caused by fix for CR 6522028