Name: clC74495 Date: 08/22/99


Carlos.Lucasius@Canada (August 22, 1999): P1/showstopper bug for Oracle.
Was able to reproduce on Win32 only (Solaris OK). Regression of bug 4033271?

--------

While a new window is being shown or activated, key events do not go to a predicable place and are often lost. This means users cannot type ahead of the application - that is, they cannot enter input for windows which have not yet fully come up yet. This is critical for us. We produce applications which are used for data entry, and it greatly reduces the productivity of data entry people if they have to wait for each window to come up before being able to enter any data. In fact, Sun itself uses our Oracle Human Resources Applications, and needs a fix for this bug.

The root of the problem is that there is a gap between the time a window is shown or activated and the time at which focus has been set to a component in that Window. Any key events that come in during this gap will go to an undefined location. On Windows, the focus will stay in the old window, then shift to the frame of the new window, then shift to the component which should get focus in the new window. So type-ahead keys will go to either the component that had focus in the old window or the frame of the new window. Neither of these is what the user expects.

I have included two test cases below. The first test case gives an example of type-ahead when a new window is being shown. A window will appear with one button in it. Press the space bar to activate this button then immediately type some characters. The button press will show a new window and cause a 3 second delay. The characters you type during this delay should appear in the text field in the new window, but they do not. They go to the button in the old window or the frame of the new window.

The second test case illustrates the case where a previously shown window is activated. When you run this test, two windows are shown. Each contains a text field. There is a two second delay built into the test case every time one of the windows is activated. If you click on the inactive window and type some characters during this delay, they will be lost. If you click back on the other window and type some more, again the keys are lost.

The only way to solve this bug is to eliminate the gap between the time a window is shown or activated and the time focus is set in the window, or to implement a type-ahead queue. It doesn't seem practical to eliminate the gap, because this would mean handling the entire activation and focus process synchronously in one shot, which would be a major change. It seems like the best thing to do is implement a type-ahead queue. We have done this in our version of the JDK, and it solves the problem. I can provide the source code for this on request, as there are too many changes to give here.

The basic premise of our solution is that when a WINDOW_OPENED or WINDOW_ACTIVATED event is posted (NOT dispatched - it needs to be done at the time it is posted or keys could get lost between the time it is posted and dispatched) you take all key events out of the main event queue and put them into a separate type-ahead queue. From then on, any new key events that come into EventQueue.postEvent() get put onto the type-ahead queue instead of the main event queue. Then, once focus is in a known state on the new window, you take all of the events out of the type-ahead queue and put them back onto the main event queue, and in the process retarget them to the newly focused component in the new window. The point at which you do this varies by platform. On Windows, it is after the FocusOnActivate message has been dispatched in WWindowPeer.java. Only at this time do you know for sure where focus should go in the newly activated window. In addition, this whole process needs to b!
!
e re-entrant in case multiple windows are shown at once.

Here are the test cases:

// Test Case 1
import java.awt.*;
import java.awt.event.*;

public class TypeAhead extends Frame implements ActionListener {

Frame w = null;

static public void main(String[] args) {
(new TypeAhead()).setVisible(true);
}

public TypeAhead() {
super("Parent Window");
Panel panel = new Panel();
add(panel);
Button button = new Button("Show Window");
button.addActionListener(this);
panel.add(button);
setSize(200,200);
addWindowListener(new WindowAdapter() {
public void windowClosing(WindowEvent e) {
System.exit(0);
}
});
}

    public void actionPerformed(ActionEvent e){
     if (w == null) {
     // Create new window and put key listener on all components
w = new Frame("New Window");
Panel panel = new Panel();
w.add(panel);
Button button = new Button("Close");
button.addActionListener(this);
TextField field = new TextField(20);
panel.add(field);
panel.add(button);
w.pack();
w.setVisible(true);
try {
Thread.sleep(3000);
} catch (InterruptedException ie) {
}
     } else {
     w.setVisible(false);
     w = null;
     }
    }
}


// Test case 2
import java.awt.*;
import java.awt.event.*;

public class TypeAhead2 extends Frame {

TextField field = null;

static public void main(String[] args) {
(new TypeAhead2("Window 1")).setVisible(true);
(new TypeAhead2("Window 2")).setVisible(true);
}

public TypeAhead2(String title) {
super(title);
Panel panel = new Panel();
add(panel);
field = new TextField(20);
panel.add(field);
setSize(200,200);
addWindowListener(new WindowAdapter() {
public void windowClosing(WindowEvent e) {
System.exit(0);
}
public void windowActivated(WindowEvent e) {
try {
Thread.sleep(2000);
} catch (InterruptedException ie) {
}
}
});
}
}
(Review ID: 94149)
======================================================================

nick.rodin@eng 08-24-1999

This bug is a duplicate of 4250987, which was escalated to JTG (see Esc. #521493). The escalation engineer had these comments:

Oracle is suggesting to backout fixes for 4109280, 4085080( I hope I am quoting
currect bugids I got these from sccs history of the source files). According
to Oracle backing out these fixes will solve the current problem. But one
of these fixes is a regression and another fix was done for Oracle itself.
Both are valid fixes which corrects the behavior of JDK. So backing out
valid fixes is not a good idea. From the bug evaluation, the stack trace
shows that JDK AWT code processes the key event and passes it on to Oracle
application code for further processing, which is destroying the windows.
This porblem if I believe is showing up on all JDKs. Oracle application
code should be modified to work properly with the corrected JDK(1.1.) rather
than the application depending on undefined/wrong behavior of the JDK.

hugo.rivero@eng 1999-08-26

This bug is not a duplicate of 4250987. While the base problem is the same, Oracle is not asking to backout existing JDK fixes, but rather to implement functionality that will allow type-ahead. This is a feature critical for any ERP applications, such as Oracle Apps.
###@###.### 10/4/04 16:41 GMT