JDK-6579743 : Regression : Java Console pops up unexpectedly in 5.0u13-b01
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 5.0u13
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2007-07-12
  • Updated: 2011-02-16
  • Resolved: 2007-09-26
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
5.0u14 b02Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Description
An applet appears in IE.
When an dialogue is invoked in the applet and the dialogue is closed, 
Java Console pops up unexpectedly in 5.0u13-b01.
The IE should go up to foreground.

REPRODUCE :
A test program and reproduing instruction(.pdf) are attached.
The issue appears to be related to the fix CR 6562716.
It doesn't occur in 1.4.2_15/ 1.5.0_12 GA/ 6u3-b01/ 7-b15.  It 's clearly a regression in 1.5.0_13 b01

Comments
WORK AROUND Quick workaround: Setting the focus explicitly. Add one extra line(this.requestFocus(); ) after : JOptionPane.showOptionDialog(this, "Hello", "Hello", JOptionPane.DEFAULT_OPTION, JOptionPane.PLAIN_MESSAGE, null, strOption, strOption[0]); So the code will look like: JOptionPane.showOptionDialog(this, "Hello", "Hello", JOptionPane.DEFAULT_OPTION, JOptionPane.PLAIN_MESSAGE, null, strOption, strOption[0]); this.requestFocus();
19-09-2007

EVALUATION Problem: Java Console goes up to top view unexpectedly in 5.0u13-b01 Fix: - modalityPopped (in IExplorerEmbeddedFrame class) is called after the dialog has been disposed and the method tries to enable the browser window. The browser window does get enabled correctly but this should have been done before the dialog was disposed. - looking at MSDN for EnableWindow() API call, these are the wordings "A window must be enabled before it can be activated. For example, if an application is displaying a modeless dialog box and has disabled its main window, the application must enable the main window before destroying the dialog box. Otherwise, another window will receive the keyboard focus and be activated. " Note that EnableWindow() call is made deep in plugin native code from the modalityPopped method. - A similar situation happens here where an applet is launched with java console open. The applet has a button which when clicked brings up a modal dialog. Close the modal dialog, the java console comes on top (instead of the focus going back to IE).Suggestion would be to enable the window before the dialog box is disposed.
18-09-2007

EVALUATION Checked the BAF+5.0u12, and noticed that the regression is there. So, good chances that it is casued by BAF.
24-07-2007

EVALUATION Some more news on this, the real problem is here: With 5.0u13, when we press the OK button from the applet(example attached with the bug), there is one window get opened and when we are doing OK or CANCEL press, the focus is not going back to the previous window. In practical, focus should go on the previous window. Just sending some detail of the event from my spy tool: With 5u12, the events goes like this: MOUSE_ENTERED MOUSE_PRESSED FOCUS_GAINED FOCUS_LOST MOUSE_EXITED FOCUS_GAINED whereas with 5u13, the event goes like this: MOUSE_ENTERED MOUSE_PRESSED FOCUS_GAINED FOCUS_LOST MOUSE_EXITED Note that: There is no event like FOCUS_GAIN again.
24-07-2007