JDK-8014821 : Regression: Focus issues with Oracle WebCenter Capture applet
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7u21,7u25
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2013-05-17
  • Updated: 2013-10-28
  • Resolved: 2013-06-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.
JDK 7 JDK 8
7u40 b31Fixed 8Fixed
Related Reports
Duplicate :  
JDK-8015652 - Regression : Focus doesn't move to button in SwingSet2 when a dialogue appears in JDK8b91
Description
WebCenter Capture product is experiencing some focus issues with their ADF web page that contains a Java applet.  These are 3 main issues:
1)      When the web page is displayed, the focus is on the first link of the ADF page.  When we press the TAB key, focus always remains within the browser page and never wants to tab into the applet.  A mouse click in the applet is always necessarily to have the applet get focus.   This issue actually happened even with Java 6.
2)      While in the applet, some user actions require a JDialog be displayed.  In Java 6, when the JDialog got displayed, it would get focus transferred to it, but in Java 7, it doesnt, so it requires a mouse click on it as well.
3)Similar in nature to the first issue, theres also an issue tabbing out of the applet to get back to the browser.  When I test with Firefox, after I tab off the last focusable component in the applet, it will correctly tab out of the applet.  In Internet Explorer, however, after tabbing off the last component in the applet, it will loop back to the first component in the applet.

Steps to reproduce:
Try to load http://adc2191118:7101/dc-client/faces/dc-client.jspx
usererid/password:  weblogic/weblogic1
(if above link is not working ten try following)
http://adc2191118:7101/dc-client
weblogic/weblogic1

After logging in, youll see the client applet in an ADF page (as seen in attached screenshot).  The applet is the area between the Oracle logo at the top and the copyright and the bottom.  On first run, it will download some client OSGI bundles, so it will take a minute or two before the clients main area is displayed.  I dont know what has the focus initially because I can't tab anywhere.  After you click in the applet, and then click on the Batch Search button(marked by arrow inside the attached screenshot), the batch search dialog will come up but it will not get focus like it used to get with Java 6. 

 Also, if you click on the Preferences ADF link(marked in attached screenshot), this calls Javascript which calls into the applet to display the preferences panel.  Focus is not given to the applet here either.
Comments
SQE: OK I tried it with 7u40 b29 as a base and test platform for before the fix state, and used a provided awt.dll as a substitute for after the fix state. The test failed and worked when and where expected. Note that I have no specific deployment-related tests and suggest to try the test in a promotion deployment run (with b30 I suppose) .
17-06-2013
The reason of the focus loss is the following. When a toplevel is shown while another toplevel is focused, native focus messages should be generated strictly in the following order: WM_ACTIVATE(WA_INACTIVE), WM_ACTIVATE(WA_ACTIVE), appropriately. The case with applet is special due to the EmbeddedFrame is not a toplevel from native platform perspective, the toplevel is the browser window. Moreover, the EmbeddedFrame window belongs to another process, other than the browser's process. It doesn't receive WM_ACTIVATE messages, these messages are generated (synthesized) for it when it should be activated/deactivated as an AWT toplevel. When EmbeddedFrame loses focus it receives WM_KILLFOCUS (which is triggered by the plugin). However, in case when a new frame pops up, the EmbeddedFrame receives WM_KILLFOCUS after the frame receives WM_ACTIVATE(WA_ACTIVE). So the order is not correct. The reason is the specific of IPC: browser -> plugin -> applet (another process). When EmbeddedFrame receives WM_KILLFOCUS it synthesizes WM_ACTIVATE(WA_INACTIVE) for itself. On processing of this message, AwtComponent::SetFocusedWindow() static method is called which resets the native pointer to the focused window. The point is that as the message is received after WM_ACTIVATE(WA_ACTIVE) (which is sent to the new frame), the new focused window is set to NULL. Later, when focus is requested to the frame's default component, it gets rejected because of the null native focused window value. Before the regression, there was a check for opposite toplevel being set focused in processing of WM_KILLFOCUS for EmbeddedFrame. In case the opposite toplevel is already set focused (which means it already received WM_ACTIVATE(WA_ACTIVE)), no WM_ACTIVATE(WA_INACTIVE) message was synthesized. DKFM in that case created a peer WINDOW_LOST_FOCUS event on java level for the toplevel losing focus (EmbeddedFrame in our case). This code was lost in the process of refactoring and I'm simply bring it back. webrev: http://cr.openjdk.java.net/~ant/JDK-8014821.7u40/webrev.0
13-06-2013
I found that jdk7 b55 is the build where it broke. Most likely, it is a regression of JDK-6806217 "implement synthetic focus model for MS Windows".
07-06-2013
attaching event log (from Spy++)
05-06-2013
Agreed it's not a new issue with 7u25 as issue exists inside 7u21 too, but it has been escalated by WebCenter Capture (issue is not reproducible with 6UR). They are asking for some easy workaround at execution time instead of user manually clicks into dialog first. If it's hard to fix then we have to inform them and by doing so they will officially treat 7u21/7u25 as not-supported platform until this issue is fixed
20-05-2013
this seems like a complex focus issues that also exists in 7u21. So it's not a new problem introduced in 7u25. can we defer this till 7u40 ? or is this escalated ? there is workaround for user to manually click on the dialog first.
20-05-2013
Jitender, can you please indicate in what build the regression was introduced and add regression label?
20-05-2013