JDK-6522028 : The print dialog moves the current IE frame to background
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 5.0u10
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2007-02-06
  • Updated: 2011-02-16
  • Resolved: 2007-07-03
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6
5.0u14 b01Fixed 6-poolResolved
Related Reports
Relates :  
JDK-6526930 - A general exception occurs when IE browser window is closed.
Relates :  
JDK-6677578 - Print dialog doesn't come up when brower window is maximized
Description
The print dialog is making the current IE frame move at the background.

To reproduce:

1. Unzip attachment file PrintApplet.zip
2. Change directory to TestApplet
3. Open file CallApplet in IE
4. Open Java Console (this is important)
5. Push button "Open New Applet" - new IE window will show PrintApplet.html file
6. Push "Print" button

You will see the print dialogue, but IE window with PrintApplet.html will move to background.
Comments
EVALUATION See suggested fix section.
21-06-2007
SUGGESTED FIX We could store the current active embeddedframe in the current appcontext just before the print dialog is invoked and use the same to set it as the parent of the print dialog.
30-05-2007
EVALUATION I would like to make a small correction here based on the above analysis. The dummy dialog is created on applet's AppContext and not on Plugin's Appcontext. I see the reason of using DummyDialog in this context as below: - We want security dialog (in this case the print permission dialog) to appear on "plugin thread group" (and not applet's thread group) for security reasons - We want the applet's EDT to be put on hold (not block UI) until the security dialog (on plugin's EDT) is disposed. - Hence we create a dummydialog on applet's EDT, make it visible. We then create the security dialog on plugin's EDT, dispose it and then hide the dummydialog which later brings up the page/print dialogs. - I tried eliminating the dummydialog and still tried to syncup applet's EDT with plugin's (using a lock object). It resulted in a hang since applet's EDT was blocked.
26-04-2007
EVALUATION The problem is not specific to the scenario when java console is open. Here is what happens: - When the print permission dialog pops up, a dummy dialog is created in the plugin thread group and so is the permission dialog itself - This dummy frame is set visible but located off the screen (-ve coordinates) - The frame obviously steals focus from whatever is the active window before the dialog was popped up. - After the permission dialog is disposed, the dummy frame is hidden and not disposed. - Now when the page or print dialog follows, attempt is made to get the active frame as its parent. - The active window would be expected to be the applet or IE frame from where the dialog was popped from - Apparently due to the dummy dialog, the focus and hence the active window either goes to java console (if it's open) and/or it may go to the dummy dialog itself. - When page/print dialog is about to be popped up, the code is being executed on the applet's appcontext and not on plugin appcontext. - java.awt.Frame.getFrames() is used to fetch all the active frames from applet's appcontext and ideally the respective IExplorerEmbeddedFrame should have been returned as the active window. But that's not the case in this bug - java.awt.Frame.getFrames() returns the IExplorerEmbeddedframes but not as the active window since the active window is either of java console or dummy dialog running on the plugin thread group. This is where we fail. Also note that we cannot get access to a frame running in another thread group. - What probably needs to be done is to find a way to restore the active window after the print permission dialog goes away. Need further investigation.
06-03-2007
WORK AROUND The policy file gives print access and hence bypasses the print confirm dialog before popping up the page/print dialog and there is no focus issue seen.
07-02-2007
WORK AROUND Use attached .java.policy.print file the following way: Rename it to .java.policy and put into your policy directory. After that the problem will disappear.
06-02-2007