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
|
Java