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.