-
Bug
-
Resolution: Fixed
-
P3
-
1.4.0
-
beta2
-
generic
-
generic
To reproduce this bug, run any applet which contains focusable Components in
appletviewer. DitherTest is a good choice. Hold down a traversal key (such as
TAB). Focus will begin traversing through all of the Components in the applet.
Now, while still holding the traversal key, open the Properties dialog from
the Applet menu.
In some cases, focus will begin cycling through the Components in the Properties
dialog. This is the correct behavior. In other cases, key events will not be
delivered to the Properties dialog at all.
I added a println to DefaultKeyboardFocusManager and noticed that the key events
are instead enqueued pending a FOCUS_GAINED event for a Component in the
*applet*, not the Properties dialog. Sure enough, setting focus back to that
Component using the mouse resyncs the focus state.
This occurs on both Windows and Solaris.
appletviewer. DitherTest is a good choice. Hold down a traversal key (such as
TAB). Focus will begin traversing through all of the Components in the applet.
Now, while still holding the traversal key, open the Properties dialog from
the Applet menu.
In some cases, focus will begin cycling through the Components in the Properties
dialog. This is the correct behavior. In other cases, key events will not be
delivered to the Properties dialog at all.
I added a println to DefaultKeyboardFocusManager and noticed that the key events
are instead enqueued pending a FOCUS_GAINED event for a Component in the
*applet*, not the Properties dialog. Sure enough, setting focus back to that
Component using the mouse resyncs the focus state.
This occurs on both Windows and Solaris.