JDK-4503980 : Focus lost/gain events get lost when gaining focus on external CDE component
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.3.1,1.3.1_01
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux,solaris_8
  • CPU: x86,sparc
  • Submitted: 2001-09-18
  • Updated: 2002-02-21
  • Resolved: 2002-01-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
1.3.1_03 03Fixed
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Description
The bug locks up entire user screens over the time.
The Swing application may loose the focus since a completely independent application gains it. The cursor in the origibal Swing textfield will still
blink (it thinks it has a focus). This feature is already a bug (cosmetic).
Gaining the focus back through <Alt><Tab> to the Swing application and clicking	
into another text field will not make the focus gain event being send to the
new textfield component.

The behaviour can be easily demonstrated by using the SwingSet application
which comes through the package in the path /usr/demo/JAVA1.2/demo/jfc/SwingSet

The bug may be reproduced by:
1.) cd  /usr/demo/JAVA1.2/demo/jfc/SwingSet
2.) /usr/j2se/bin/java -jar SwingSet.jar
3.) Pick tabbed pane >Labels<
4.) Get focus on textfield >Type here< by clicking the mouse into it.
5.) Enter abc
6.) Gain focus on a dtterm by clicking on the the frame

Error1: The cursor of the text field is still blinking.
	It has not got a focus lost event.
7.) Gain focus on the swing application by using the key combination <ALT><TAB>

8.) Click with mouse on text field <and here>

Error2: Textfield >Type here< does not get a focus lost event since the cursor
	is still blinking
Error3: The textfield >and here< does not get a focus gained event since no
	cursor pops up

The field >and here< can be used for input
Everything start getting messy: Two cursor are now blinking ...

The real live application get screwed up since additional action like high lighting are being triggered the right way...



Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.3.1_03 FIXED IN: 1.3.1_03 INTEGRATED IN: 1.3.1_03
24-08-2004

EVALUATION To reproduce this I ran with the SwingSet.jar from /usr/local/java/jdk1.2.2/solaris/demo/jfc/SwingSet. We appear to now be getting the FocusLost events, so that the text cursor will stop blinking. Unfortunately when you use alt-tab to get back to SwingSet no one has focus (KeyboardFocusManager.getCurrentKeyboardFocusManager().getFocusOwner() == null). You can see the same behavior with SwingSet2 if you click in one of the text fields in the split pane demo, then click on an external window and then hit alt-tab. ###@###.### 2001-09-18 Investigate for Merlin ###@###.### 2001-09-18 Assigning to Russia. ###@###.### 2001-09-18 Name: dmR10075 Date: 09/19/2001 ###@###.### Below is the evaluation for Merlin, tested with Merlin b78 In native code we listen only for one kind of Focus event - one with mode == NotifyNormal. When one uses special key sequences handled by WM which make windows focused/unfocused WM sends different kinds of Focus events (for example on my IceWM I receive FocusOut NotifyGrab, then NotifyWhileGrabbed when I switch out of application, then FocusIn NotifyWhileGrabbed, NotifyUngrab when I switch back). We skip all this events in awt_MToolit.c:processOneEvent. If you have Java windows focused and click with mouse to another window on desktop then Java receives FocusOut NotifyNormal which we process and CLEAR focus. Therefor when you switch back using key sequence, and we doestn't receive any Focus events we listen to, we doesn't restore focus and frame looks active and not having focus. To restore focus you can just click on the component you want to make it focused. I was unable to reproduce problem with two cursors. I was able to reproduce the problem reported by Scott Violet, workaround exists however. Workaround: ###@###.### Don't mix mouse and keyboard application switch, if you switched out of Java by mouse return back also by mouse. If you switched out of Java by keyboard, you can switch back either by keyboard or mouse. ====================================================================== To summarize the investigation: The problem the submitter describes sounds very serious. However, we were not able to reproduce it in 1.4. It was probably fixed by the focus rearchitecture we did in 1.4. There is a remaining problem in 1.4, described by ###@###.### and ###@###.### in the Evaluation above. That problem is not as serious, and can be addressed in a later release. I will file a separate bug about it: 4504821 Because the problem in the Description does not exist in the current release, I am downgrading the priority of this bug to 4 (standard practice). If a fix is needed in a release prior to 1.4, it must be handled as a technical escalation through CTE. I will leave this report open for the convenience of CTE, in case the problem is escalated. ###@###.### 2001-09-19 In this case NotifyWhileGrabbed is received for the ALT+TAB action. We can then handle this in awt_TopLevel.c:shellEH() which in turn calls MWindowPeer.handleActivate() for the window being tabbed to. This is sufficient to give expected behaviour and fix the bug. ###@###.### 2001-09-27 Name: rpR10076 Date: 11/16/2001 commit to hopper and tiger ====================================================================== ###@###.### 2002-02-04 commit to 1.4.0_01 removing the commit to 1.4.0_01. This bug doesn't actually appear in 1.4 - instead the problem described by Scott and Eric above does (4504821), i.e. none of the lightweights regain focus and you have to use the mouse to access anything in the Java window after ALT-TABing in. I had originally thought that there was an accessibility issue here but seeing as you have to click OUT of the window in the first place there is no accessibility problem. ###@###.### 2002-02-21 Since this bug does not occur in 1.4 or later, I'll decommit it from hopper. ###@###.### 2002-02-21
21-02-2002