JDK-6374321 : Textfield loses focus after alt key hit in IE browser
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2006-01-19
  • Updated: 2011-01-19
  • Resolved: 2006-04-15
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
1.4.2_12Fixed 6 b81Fixed
Related Reports
Relates :  
JDK-6332100 - Focus lost in Textfield after doing a back/forward from Internet Explorer using
Relates :  
JDK-6527314 - IE applet looses focus after migrating from 1.4.2_10 to 1.4.2_13
Relates :  
JDK-6383397 - Alt button is hiding mouse wheel event
Description
Text field loses focus (caret doesn't blink) when alt key is hit (twice) in the following applet :

http://rain.ireland/~sc87771/6332100/orig/sc.html

When using a pure awt version of this applet this problem is not seen :
http://rain.ireland/~sc87771/6332100/ms/sc.html

Seen on mantis,tiger and mustang.
Hitting the tab key will restore the focus in the swing version.
CR 6332100 is similar but involves using alt-tab and is reproducible in pure awt version.
Comments
SUGGESTED FIX See the webrev here: http://javaweb.sfbay/jcg/1.6.0-mustang/awt/6374321
04-04-2006
EVALUATION It has appeared the some time back we already resolved some problem that was symmetric to this one. That is when a component inside an applet loses focus we send synthetic WM_ACTIVATE(WA_INACTIVE) to deactivate the EmbeddedFrame. So, the same should be done when a component gets focus from outside whereas the EmbeddedFrame is not active. We have to send it WM_ACTIVATE(WA_ACTIVE) to activate it synthetically. I'll come up with diffs some time later. The point is that the diffs depend on the fix for 2134972 that is being reviewed so far.
03-03-2006
EVALUATION Some investigation showed the following. When user hits Alt in IE focus goes into menu. This is triggered on native level as well as what happens after user hits Alt the second time. Somehow Windows retains previous focus owner and returns focus to it via sending WM_SETFOCUS (::SetFocus(HWND) is called). This actually breaks the mechanism AWT uses to restore focus on the most recent focus owner. This mechanism is based on that the window should be activated at first, i.e. it has to receive WM_ACTIVATE message. After that, on Java level, AWT requests focus on the most recent focus owner when it handles WINDOW_GAINED_FOCUS Java event. However in the case being discussed EmbeddedFrame doesn't get activated, instead, as I said, native component gets WM_SETFOCUS event. In case of pure AWT app, KeyboardFocusManager manages this correctly in some way. But Swing component is lightweight and it's heavyweight container which receives WM_SETFOCUS from native system. That's why the panel, but not the JTextField gets focus in the testcase.
22-02-2006
EVALUATION I'm requesting AWT help with this. Here's what I've discovered: When the first ALT is hit, focus is lost from the JTextField and sent to the menu item in the browser. The second ALT returns focus to the applet. However, focus goes to the Applet component itself and is not restored to the JTextField that has focus. This same problem does not happen if the JTextField is replaced with an AWT text field. It seems that focus is automatically returned to any AWT component, but not Swing component. I expect that there is something in the AWT focus system that is working favorably for AWT components but not properly for Swing. I'm hoping AWT has an idea what this is.
10-02-2006