EVALUATION

Here is the link to the IDR sent to Forms team on June 17.
/net/jpsesvr/jpse-US1/rp203170/windows/tools/idr/idr-1661121021

This includes fix for:
1. typeAhead marker issue
2. Alt+Tab menu issue

Here is the webrev for the fix: http://jpsesvr.us.oracle.com:8080/ctetools/CodeStore/3796/webrev/index.html

Updating as per internal call on June 27th:
Forms and Ewt teams have verified the IDR and this fixes the following issues:
1. As per bug filed originally.
2. Alt+Tab highlighting the Menu bar

However they see another related problem, that when separateFrame (new browser window is opened) is used , tabbing 5 times brings focus to 4th item instead of 5th. As this is a browser related issue, they will be a new bug along with test case to track it.

At present the above fixes resolve customer problem to large, hence the plan is to ask GE to verify the fix and once verified we integrate the current fix into the JRE.
                                     

SUGGESTED FIX

Here is the latest fix webrev:

http://javaweb.us.oracle.com/~rp203170/6981400/June16/webrev
                                     

EVALUATION

This evaluation is for regression 7013024, 7013644

Here is my further understanding ...
When using the mouse the marker queue has the marker time incorrect for the components.
As you had asked me to watch the marker queue , here is the analysis based on that:

Scenario 1: using keyboard
==========================
When I use the keyboard, where the component with focus is javax.swing.JCheckBox , the marker queue looks as follows:

FINEST: >>> Markers dump, time: 1,299,702,715,093
FINEST: >>> Marker after 1299702714921 on com.sun.deploy.panel.CacheSettingsDialog[dialog0,273,127,476x364,layout=java.awt.BorderLayout,APPLICATION_MODAL,
    title=Temporary Files Settings,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,3,29,470x332,layout=javax.swing.JRootPane$RootLayout,
    alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
FINEST: >>> Marker after 1299702714921 on javax.swing.JCheckBox[,12,12,209x23,alignmentX=0.0,alignmentY=0.5,border=javax.swing.plaf.BorderUIResource$
    CompoundBorderUIResource@2e323,flags=424,maximumSize=,minimumSize=,preferredSize=,defaultIcon=,disabledIcon=,disabledSelectedIcon=,
    margin=javax.swing.plaf.InsetsUIResource[top=2,left=2,bottom=2,right=2],paintBorder=false,paintFocus=true,pressedIcon=,rolloverEnabled=true,
    rolloverIcon=,rolloverSelectedIcon=,selectedIcon=,text=Keep temporary files on my computer.]


When javax.swing.JCheckBox receives focus (FOCUS_GAINED) all markers in the queue are deleted up to the current match i.e javax.swing.JCheckBox itself.
So the marker queue is empty.  And when the keyevent occurs it is correctly processed by javax.swing.JCheckBox the current item in focus.

Scenario 2: using mouse
========================
Here is where the problem is seen, when I use the mouse, the expected Focus on javax.swing.JCheckBox , the marker queue looks as follows:
The marker queue has typeAheadMarker 1) for the javax.swing.JCheckBox. first and 2) then for the com.sun.deploy.panel.CacheSettingsDialog,
where it should be 2 & 1.
This is due to incorrect time which is from Comonent.java#requestFocusHelper(), EventQueue.getMostRecentEventTime()
which is called to get the time and then used as 'after' in marker (also that time is passed to requestFocus() )

As this queue is created incorrectly due to the 'after' time, we see all the issues.

FINEST: >>> Markers dump, time: 1,299,546,458,093
FINEST: >>> Marker after 1299546455875 on javax.swing.JCheckBox[,12,12,209x23,alignmentX=0.0,alignmentY=0.5,border=javax.swing.plaf.
    BorderUIResource$CompoundBorderUIResource@70610a,flags=424,maximumSize=,minimumSize=,preferredSize=,defaultIcon=,disabledIcon=,disabledSelectedIcon=,
    margin=javax.swing.plaf.InsetsUIResource[top=2,left=2,bottom=2,right=2],paintBorder=false,paintFocus=true,pressedIcon=,rolloverEnabled=true,
    rolloverIcon=,rolloverSelectedIcon=,selectedIcon=,text=Keep temporary files on my computer.]
FINEST: >>> Marker after 1299546457890 on com.sun.deploy.panel.CacheSettingsDialog[dialog0,273,130,476x364,layout=java.awt.BorderLayout,
    APPLICATION_MODAL,title=Temporary Files Settings,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,3,29,470x332,
    layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],
    rootPaneCheckingEnabled=true]

Now when FOCUS_GAINED is received by component javax.swing.JCheckBox, it deletes the markers in queue until it reaches its current matched component. So the
new queue looks as
FINEST: >>> Marker after 1299546457890 on com.sun.deploy.panel.CacheSettingsDialog[dialog0,273,130,476x364,layout=java.awt.BorderLayout,
    APPLICATION_MODAL,title=Temporary Files Settings,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,3,29,470x332,
    layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],
    rootPaneCheckingEnabled=true]

The current focussed component is  javax.swing.JCheckBox, so when key is pressed and KeyEvent time is checked (see below), the
KeyEvent time (ke.time=1299546458843) is higher than the marker time(maker.after=1299546457890), so the KeyEvent is stored and not dispatched.

Mar 7, 2011 5:07:39 PM java.awt.DefaultKeyboardFocusManager pumpApprovedKeyEvents
FINER: DKFM: RP: ke.time=1299546458843 maker.after1299546457890
Mar 7, 2011 5:07:39 PM java.awt.DefaultKeyboardFocusManager typeAheadAssertions
FINER: Storing event java.awt.event.KeyEvent[KEY_RELEASED,keyCode=32,keyText=Space,keyChar=' ',keyLocation=KEY_LOCATION_STANDARD,rawCode=32,
    primaryLevelUnicode=32,scancode=57] on dialog0 because of marker >>> Marker after 1299546457890 on com.sun.deploy.panel.CacheSettingsDialog[dialog0,
    273,130,476x364,layout=java.awt.BorderLayout,APPLICATION_MODAL,title=Temporary Files Settings,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=
    javax.swing.JRootPane[,3,29,470x332,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,
    minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]


Scenario3 : using mouse: without fix for 6981400
===================================================
With backing out the fix of 6981400, when I use the mouse the queue has the entries as 1) CacheSettingsDialog and 2) JCheckBox next in the queue.

FINEST: >>> Marker after 1299798790250 on com.sun.deploy.panel.CacheSettingsDialog[dialog0,273,127,476x364,layout=java.awt.BorderLayout,
    APPLICATION_MODAL,title=Temporary Files Settings,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,3,29,470x332,layout=
    javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
FINEST: >>> Marker after 1299798790375 on javax.swing.JCheckBox[,12,12,209x23,alignmentX=0.0,alignmentY=0.5,border=
    javax.swing.plaf.BorderUIResource$CompoundBorderUIResource@e8a021,flags=424,maximumSize=,minimumSize=,preferredSize=,defaultIcon=,disabledIcon=,
    disabledSelectedIcon=,margin=javax.swing.plaf.InsetsUIResource[top=2,left=2,bottom=2,right=2],paintBorder=false,paintFocus=true,pressedIcon=,
    rolloverEnabled=true,rolloverIcon=,rolloverSelectedIcon=,selectedIcon=,text=Keep temporary files on my computer.]


To Fix:
======
So whether mouse or keyboard is used, adding an additional check in EventQueue:setCurrentEventAndMostRecentTimeImpl for MouseEvent, sets the time in the Marker queue correctly in
DKFM:enqueueKeyEvents.

    if ((e instanceof KeyEvent) || (e instanceof MouseEvent)){
         mostRecentKeyEventTime = ie.getWhen();
     }
The initial fix (of 6981400) was to check for "if ((e instanceof KeyEvent) " modifying it to above to set the current time for KeyEvent or MouseEvent,
which is then passed in
Component.java, in requestFocusHelper(), to getMostRecentKeyEventTime() to get the time to pass it on to requestFocus(), helps resolve the issue.
                                     

EVALUATION

In the typeAheadMarker the 'time' that is being used while creating the typeAheadMarker should at be least equal to the most recent event time and not more than that. Currently, it uses the current-time rather than most recent event time for the 'marker' creation.

In Comonent.java#requestFocusHelper(), EventQueue.getMostRecentEventTime() is called to get the time and then that time is passed to requestFocus() and then used as 'after' in marker.

Now, setCurrentEventAndMostRecentTimeImpl() handles all the AwtEvents and sets the mostRecentEvent time. So the time returned by getMostRecentEventTime() is not the time of the last KeyEvent but of any latest AwtEvent. And it is almost always equal to the current time because events like below one keep getting dispatched continuously.

EventQueue: old recent time: 1287060229156 new recent time: 1287060229703 Event is:java.awt.event.InvocationEvent[INVOCA
TION_DEFAULT,runnable=javax.swing.Timer$DoPostEvent@16f144c,notifier=null,catchExceptions=false,when=1287060229703] on s
un.awt.windows.WToolkit@1175422

So, there should be a separate variable in EventQueue to get the mostRecentKeyEventTime and that should be used while creating the marker for enqueuing the Key Events.

So the changes are:----

In EventQueue.java:
-------------
Add new variable mostRecentKeyEventTime,
private long  mostRecentKeyEventTime = System.currentTimeMillis();

set this in setCurrentEventAndMostRecentTimeImpl()

        if (e instanceof InputEvent) {
            InputEvent ie = (InputEvent)e;
            mostRecentEventTime2 = ie.getWhen();
            if (e instanceof KeyEvent) {
                mostRecentKeyEventTime = ie.getWhen();
            }

Add accessor function for it:
    public synchronized long getMostRecentKeyEventTime() {
        return mostRecentKeyEventTime;
    }

In Component.java, in requestFocusHelper(), use getMostRecentKeyEventTime() to get the time to pass  it on to requestFocus():
------------------
        // Focus this Component
        long time = Toolkit.getEventQueue().getMostRecentKeyEventTime();      
        boolean success = peer.requestFocus
            (this, temporary, focusedWindowChangeAllowed, time2, cause);
        if (!success) {
                                     

EVALUATION

"The most recent event time" value is set via calling EventQueue.setCurrentEventAndMostRecentTime(AWTEvent).
The method is called in Component.dispatchEventImpl(AWTEvent) for all the events being dispatched.
For key events it's additionally called in DefaultKeyboardFocusManager.preDispatchKeyEvent(KeyEvent).

The latter method is called in one of the following cases:

1. When a KeyEvent is being dispatched by DKFM (Component.dispatchEventImpl -> DKFM->dispatchEvent ->
   DKFM.typeAheadAssertions), and the event's time stamp is lesser than the time of the earliest marker
   (if any). This means the event had been generated before the earliest focus request, currently
   in progress, happened.

2. When a KeyEvent is dequeued on FOCUS_GAINED dispatching (Component.dispatchEventImpl(FocusEvent) ->
   DKFM->dispatchEvent -> DKFM.typeAheadAssertions -> DKFM.pumpApprovedKeyEvents) if its time stamp
   is lesser than the time of the earliest marker (if any) after removal of the marker corresponding
   to the FOCUS_GAINED event.

However the key event is not really dispatched to its target but is queued (in the 1st case) or
remains in the queue (in the 2nd case) if its time stamp is greater than the time of the earliest marker.
In this case "the most recent event time" value should not be set to the key event's time stamp.

So, the first call of EventQueue.setCurrentEventAndMostRecentTime(AWTEvent) should not be made for
a KeyEvent (i.e. we should check for !(event instanceof KeyEvent)).

The EventQueue.setCurrentEventAndMostRecentTime(..) method, besides updating the most recent time,
sets current event being dispatched from EventQueue. What can we break if a key event that is
queued (whose real dispatching is postponed) will not be set to "the current event" until it's
really dispatched to its target?

The EventQueue.currentEvent, as well as EventQueue.mostRecentEventTime fields are used by AWT & Swing
when some action (like a focus request or creating new ActionEvent etc.) should be associated with
the event (being dispatched) that caused this action. A KeyEvent that is not really dispatched but
queued cannot cause any actions or requests. Thus, I believe, postponing stamping of a key event
to the moment of its real dispatching should not break anything.

By the way, in the CR 4434193 I've found some useful information related to the things being discussed
from the first hands (the author of the core focus architecture in JDK 1.4).
                                     

EVALUATION

Please, don't forget that in understanding of the "focus flow" it's really helpful to turn on the focus logger -
java.awt.focus.level=ALL.

Below I'm trying to shed some light on a part of the focus mechanism that is responsible for "Type Ahead".

  Events of some particular types have a time stamp which indicates the moment of the event creation.
  These events are: InputEvent, InputMethodEvent, ActionEvent & InvocationEvent. For now we're interested
  in KeyEvents which belong to InputEvents. A key event is created in the AWT native message procedure
  where it's given a time stamp.
  
  Focus is asynchronous. It might happen that a series of some user actions leads to a series of focus
  transfers being processed much later. Nevertheless, a connection b/w cause and effect should be
  somehow established. For that purpose, AWT uses a notion of "the most recent event time" which is set
  to the time stamp of the most recent event (of some of the types listed above) that has been dispatched
  from EventQueue. A focus request is associated right with the most recent event time. Thus, the events
  and the focus requests caused by them are put on to a time scale so that AWT can judge which one happened
  before and which one after.

  Additionally, when a focus request is being processed, mapping b/w the request's time and the component
  requesting focus is created and is put into "the queue of markers". The first (the earliest) marker is used
  to make a comparison with key event's time stamp. When a key event is being dispatched, if its time is
  greater than the time of the marker, the key event is queued. Thus the event is not dispatched until
  processing of all the focus requests, happened before the event, are completed. The queue of markers
  is inspected every time a new component gains focus. The marker associated with the component is removed
  from the queue. Along with it, the queued (postponed) key events are also inspected. Those which came
  before the earliest marker time (or all the events if the queue of markers is empty) are dispatched to
  the current focus owner. The resting events are waiting for their turn.

  This mechanism allows to deliver key events to right components even when a user "types ahead", that is
  when the events happen in the middle of an ongoing focus transfer.


Now, with this info in mind, an explanation of what's going on in the testcase follows.
Below, Text1, Text2, Text3 and Text4 are the text components in the test. Tab1, Tab2 and Tab3 are
three tab events. t1,...,tn are time stamps.

- Working scenario: pressing TAB three times, no switch b/w toplevels.

1. Tab1 is dispatched to Text1. t1 is set to "the most recent event time".

   1.1 Focus is requested to next Text2. [t1 -> Text2] marker is created and queued.
  
2. FOCUS_LOST is dispatched to Text1.

   2.1 Waiting for 5 sec...

3. FOCUS_GAINED is dispatched to Text2.

   3.1 Focus is requested to Text2 (in the testcase).

       3.1.1 The request is ignored as Text2 is already the focus owner.

   3.2 [t1 -> Text2] marker is removed from the queue.

4. Tab2 is dispatched to Text2. t2 is set to "the most recent event time".

   4.1 Focus is requested to next Text3. [t2 -> Text3] marker is created.

5. Tab3 is dispatched to Text2. t3 is set to "the most recent event time".

   5.1 Tab3's time is compared with the marker's t2 time.
       t2 happened before, so Tab3 is queued (postponed).

6. FOCUS_GAINED is dispatched to Text3.

   6.1 [t2 -> Text3] marker is removed.

   6.2 Inspecting the queued key events:

       6.2.1 Tab3 is dispatched to Text3 as the marker's queue is empty.

             - Focus is requested to Text4...

7. Text4 eventually gains focus.


So, "type ahead" works fine here.


- Failing scenario: pressing TAB three times, switching to another toplevel and back.
       
1. Tab1 is dispatched to Text1. t1 is set to "the most recent event time".

   1.1 Focus is requested to next Text2. [t1 -> Text2] marker is created and queued.
  
2. FOCUS_LOST is dispatched to Text1.

   2.1 Waiting for 5 sec...

3. Switch to another toplevel, switch back.

4. FOCUS_GAINED is dispatched to Text2 (the result of 1.1)

   4.1 Focus is requested to Text2 (in the testcase).

       4.1.1 The native focus owner is null (due to 3.), so the request is accepted.
             [t1 -> Text2] marker is created.

5. Tab2 is dispatched to Text2. t2 is set to "the most recent event time".

   5.1 Tab2's time is greater than the marker's t1 time, so Tab2 is queued.

6. Tab3 is dispatched to Text2. t3 is set to "the most recent event time".

   6.1 Tab3 is also queued (see 5.1)

7. WINDOW_LOST_FOCUS, WINDOW_GAINED_FOCUS are dispatched to the frame in order.

   7.1 Focus is requested to Text2 (the most recent focus owner). [t3 -> Text2] marker is created and queued.

8. FOCUS_GAINED is dispatched to Text2 (the result of 4.1)

   8.1 Both the markers are deleted.

   8.2 Inspecting the queued events:

       8.2.1 Tab2 is dispatched to Text2. Focus is requested to the next Text3. [t3 -> Text3] marker is created.

       8.2.2 Tab3's time is not greater than t3, so Tab3 is also dispatched to Text2.

9. Text3 gains focus (the result of 8.2.1).


It can be seen that Tab3 didn't go to Text3. The time stamps went wrong...

At 8.2.1 the focus request is associated with t3, though it's really the result of Tab2,
so t2 would be expected here. t3 is set at 6., however the Tab3 event was not actually dispatched
but only queued. So it could not be a cause of any request, why setting "the most recent event time"
for it? 

The latter is just my current assumption: we probably shouldn't stamp time for key events that are not
dispatched but queued (postponed). Simply trying this idea fixes the problem... though, I should
thoroughly check if this is a valid solution.
                                     

EVALUATION

See comments.
                                     

EVALUATION

Hi Prashant,
Here is further explanation to the focus issue using your application log :

Case 1: Application doesnt switch tasks. In this case the jt1.requestFocus(); doesnt do anything as the current application itself is in focus.
FG JT1
FL JT1
FG JT2 s
FL JT2
FG JT3
FL JT3

Case 2: With switching tasks to another app and coming back:
When I switch application here is the log
focusLost
FG JT1
FL JT1
FG JT1
FL JT1
FG JT2 s
FL JT2

As you see the code "jt1.requestFocus(); " code gets executed / used. This is causing on alt+tab when application loses focus to execute the focusGained + focusLost to execute twice. hence you FG JT1 + FLJT1 twice in the log

Please read the Focus subsystem document to keep this in mind for your design:
http://download.oracle.com/javase/tutorial/uiswing/misc/focus.html

Hence going back again this is not a bug and please evaluate your logic accordingly.

Regards,
Ragini.