JDK-6527314 : IE applet looses focus after migrating from 1.4.2_10 to 1.4.2_13
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.2_13
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2007-02-21
  • Updated: 2011-02-16
  • Resolved: 2008-12-17
Related Reports
Relates :  
JDK-6374321 - Textfield loses focus after alt key hit in IE browser
Description
Customer has a very complex environment where 200 windows applications are running in different browsers under one single container process. So each might request focus depending on their process flow. Main problem that they noticed is that event with mouse also focus is not getting set and they can't type within a text field!

Everything was fine in 1.4.2_10. They noticed the problem with 1.4.2_13. 

There is one applet which is loaded inside a windows container process. There are 11 similar applets running in same container process. After applet is loaded, sometimes it does not allow them to type and cursor is often missing. Then even if they click mouse in a text field still it doesn't allow them to type! Other key like - Tab also doesn't work as expected. Only when applet is refreshed by user other action (like clicking a different button or outside applet area and coming back) it allows typing and focus returns.

The problem shows up in IE. As they do not use other browsers, they did not test them.

They recompiled the applets, which did not fix the problem.

A screenshot showing the image is attached. It shows the the textbox next to label SELECT that is where focus should be and is most of the times. But sometimes even if that block cursor is displayed they can't type and clicking mouse also won't help! See HODApplet.ppt

They submitted a trace using -Djavaplugin.trace=true. See plugin142_1321ctestuser1468-952028337.trace.

For debugging, thye turned a thread on to monitor where the focus is. Following is one snapshot when problem happened. This shows all the components within the applet and reports focus was not there. You can see all java AWT/Swing components it has inside the applet.

2007-02-15 11:06:43.726 FocusMonitor-A[HHCj] Component com.ibm.eNetwork.beans.HOD.Terminal

2007-02-15 11:06:43.726 FocusMonitor-A[HHCj] Component mlhod.MLHODSession

2007-02-15 11:06:43.726 FocusMonitor-A[HHCj] Component javax.swing.JPanel

2007-02-15 11:06:43.726 FocusMonitor-A[HHCj] Component javax.swing.JLayeredPane

2007-02-15 11:06:43.726 FocusMonitor-A[HHCj] Component javax.swing.JRootPane

2007-02-15 11:06:43.726 FocusMonitor-A[HHCj] Component com.ibm.eNetwork.HOD.cached.appletloader.JSCachedAppletLoader

2007-02-15 11:06:43.726 FocusMonitor-A[HHCj] Component sun.plugin.AppletViewer

2007-02-15 11:06:43.726 FocusMonitor-A[HHCj] Component sun.plugin.viewer.frame.IExplorerEmbeddedFrame

2007-02-15 11:06:43.726 FocusMonitor-A[HHCj] did not find the focus
The customer sent in more information. A screen shot is attached. He says they have 11 applets running under one JVM and there is some kind of synchronization applied for business functions.

Following is a snapshot of four applets running in separate browsers controlled by the container. You can see the cursor in top-left applet. This is how it should work. But sometimes there is no cursor and focus is lost. Even mouse click on applet won���t return the focus!
Customer opened a WebEx session to demonstrate the problem they are having with applets. They are using IE and 1.4.2_13. Their application uses 11 applets. He showed one view that displayed 4 applets. 

He demonstrated the problem. 

* clicked on the text box in one applet.
* opened a second application.
* returned to the first application, where he could not type in a text box.

Here is the description of the problem.

* When he returns to the application, the selected applet has the focus. The applet has a blue border around it while the other applets are gray.

* Mouse events in the applet work. He can right-click the mouse to open a pop-up window. The MouseListener EventListener continues to grab focus. 

* Keyboard events stopping working. He cannnot type in the textbox selected by the mouse. Tab keys do not work. The KeyListener EventListener no longer has focus so when a key is pressed, released, or typed and nothing happens.

* His MouseListener EventListener includes a call to the KeyListener EventListener to make sure keyboard events work. Even though mouse events work, he still cannot get any keys to work.

* This problem was first noticed in 1.4.2_13. They did not have the problem with 1.4.2_10.

This suggests the problem is a KeyListener EventListener one. The customer has 30,000 users. They must go to 1.4.2_13 as soon as possible due to Sun Alert 102760.
Comments
EVALUATION I tried to start 12 applets (with text fields) in IE with JDK 1.7 but I wasn't able to reproduce the bug. I'm afraid this is all what I can do for now. I can't build 1.4.2, I'm not able to run the original test app. So, I'm reassigning the CR to CTE. What I can advice is the following. As Artem wrote above we have two CRs suspected: 6435715 (1.4.2_13) and 6374321 (1.4.2_12). So, at first it would be helpful to refine in what update release the problem has appeared - 12 or 13? Then, build a test JDK (or two) with that fixes rolled out and provide a cu with it for testing. Aslo, it would be great to know if the cu can see the problem with JDK 7.0, if it's possible.
28-02-2007
EVALUATION The customer asks to address this issue soon. To help us, he is setting up a WebEx session on Friday, February 23 to show us this issue if can't be reproduced by us. He is asking us when we are available. (I'm not sure how to address--this is the first I had a customer ask engineering to attend a concall to view a WebEx session)
23-02-2007
EVALUATION I see the following fixes in 1.4.2_11 - 1.4.2_13, related to focus management: 6435715, 6448190 and 6374321. The problem described in 6448190 is also reproducible with 1.4.2_10, so it is unlikely to be the source of this regression.
22-02-2007