Bug ID: JDK-6677578 Print dialog doesn't come up when brower window is maximized

Type: Bug
Component: client-libs
Sub-Component: java.awt
Affected Version: 5.0u14

Priority: P2
Status: Resolved
Resolution: Fixed
OS: windows
CPU: x86

Submitted: 2008-03-19
Updated: 2011-02-16
Resolved: 2009-01-07

Other	Other
5.0u17-rev b09Fixed	5.0u18Fixed

Print dialog doesn't come up when brower window is maximized.

This is IBIS case 70045332.
Customer recently migrated from MSJVM to Sun 5.0u14 JRE
and run into this issue.

The print dialog window comes up normally if the browser window 
is NOT maximized, but is missing most of the times if the brower window is maximized.

This is consistently reproducible with IE and 5.0u14 JRE.

The behavior is much more erratic with firefox.

The testcase and step by step instruction to reproduce is
described in the IBIS case notes, since it contains customer data.
open IBIS escalation #80134439

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.
15-09-2008
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
08-09-2008
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) {
18-06-2008
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.
18-06-2008
EVALUATION This is regression caused by fix for CR 6522028
15-05-2008