JDK-6527109 : Focus problems with two SWT_AWT components inside a single SWT shell
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: generic
  • Submitted: 2007-02-21
  • Updated: 2011-03-07
  • Resolved: 2011-03-07
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
7 b15Fixed
Related Reports
Relates :  
JDK-6557375 - Focus is lost when tabbing SWT_AWT to SWT to SWT_AWT
Relates :  
JDK-6432035 - Unable to edit content of JTextField intermittently following modal dialog
Relates :  
JDK-6469096 - requestFocusXXX on unfocused window causes incorrect results under X
Description
Launch the attached test on linux/solaris (SWT-GTK is required). The test creates an SWT top-level shell and adds three components to it: AWT text area, SWT text field and AWT text field. AWT components are laid to separate SWT_AWT composites (embedded frames).

The first problem is that in some cases no one of the components is focused when the window is shown. According to the XEmbed log, SWT shell first sends XEMBED_FOCUS_IN to the text area and then to the text field, so I expect the text field to be focused. However, only two cases are possible: focus is nowhere or focus is in the text area - both are wrong.

Then, when focus is initially in the text area, the second problem appears. If I click the text field with mouse, it doesn't get focused. But if I click the SWT text area first, then focus starts working properly.
Comments
EVALUATION I've tested the problem with fix for 6469096 and it looks like it fixes this problem too. So, I'm marking this CR as fix available too, to gives our SQE chance to test this.
15-05-2007
EVALUATION The problem is as follows: 1. we receive XEMBED_FOCUS_IN (XEMBED_FOCUS_CURRENT) on the first frame (frame0) 2. post WINDOW_GAINED_FOCUS for frame0 3. receive XEMBED_FOCUS_OUT on frame0 4. receive XEMBED_FOCUS_IN (XEMBED_FOCUS_CURRENT) on the secod frame (frame1) 5. post WINDOW_GAINED_FOCUS for frame1 6. KFM dispatches WINDOW_GAINE_FOCUS on frame0 and calls request focus on its default component (text area) 7. requestFocusInWindow() calls KFM.shouldNativelyFocusHeavyweight() which thinks that frame0 is native focused window now (but it is not, since we have already received XEMBED_FOCUS_OUT for it) and allows the request, so we send FOCUS_GAINED for text area. 8. KFM dispatches WINDOW_GAINE_FOCUS on frame1 and call request focus on its default component. 9. requestFocusInWindow() calls KFM.shouldNativelyFocusHeavyweight() which denies the request since there is a pending focus request for another toplevel. So, at the end java thinks that focus is in frame0, but SWT/gtk thinks that it is in frame1, and so does not respond to our focus requests for this frame. I think that we should fix step 7. shouldNativelyFocusHeavyweight() must know correct native focused window. SO, I'd say that this bug has the same root cause as for 6469096 (requestFocusXXX on unfocused window causes incorrect results under X)
21-02-2007