JDK-4163339 : Arrow Keys does not work in most of the SMC dialogs; input methods disabled
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: solaris_7,1.1.7,1.2.0,1.3.0
  • Priority: P2
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: solaris_7,solaris_9
  • CPU: generic,sparc
  • Submitted: 1998-08-04
  • Updated: 1999-06-09
  • Resolved: 1999-06-09
Related Reports
Duplicate :  
JDK-4191281 - Solaris7: Pressing arrow keys causes Components to lose focus
Duplicate :  
JDK-4270451 - Using arrow keys on Solaris results in focusLost/focusGained
Relates :  
JDK-4214799 - Solaris: Component focus is lost when using menu
Description
In almost all the dialogs which I traversed through, the arrow keys does not seem to work at all. Backspace key though works fine.

The Login dialog of SMC seems to be an exception to this.


Description from 4191281, which was closed as a duplicate of this bug:

Pressing an arrow key causes Components to lose focus and, therefore, you can't type any keys further. This happens only on one of two Japanese Solaris 7 machines.

What we found out are:

  - This doesn't depend on a locale. (i.e., reproducible in both C and ja locales)
  - This often (not always) causes a Japanese input method to freeze.
  - This is reproducible using Notepad, Stylepad, InputDislog of SwingSet and IMFTest (test/java/awt/im/IMFTest).
  - This is not reproducible using PlainText and other components of SwingSet.
  - If Canvas instead of Component is used in IMFTest, it's no longer reproducible in C locale, but still reproducible in ja locale. This means it's possible that there are two separate problems with arrow keys.
Comments
WORK AROUND Use the arrow keys on the keypad (with numlock turned off).
11-06-2004
SUGGESTED FIX jenny.wang@East 1999-05-20 This bug has been fixed. The code I putback for bug#4124119 and bug#4124969 also fixed this bug. They all related to the temporary FOCUS_OUT event, even though they show up in different ways. See bug#4124119 Suggested Fix field for the butback. jenny.wang@East 1999-06-09 See bug#4241538 X Suggested Fix field for a new fix.
09-06-1999
EVALUATION This seems to be a problem with the application's interaction with dtwm. The problem is that, when the key bindings supplied in the comments of this bug report are specified in the dtwmrc file, the cde window manager issues focus requests in response to arrow keys. These focus requests cause a FocusOut event generated on the window frame, followed by a FocusIn event. This seems like a bug in the cde window manager, since, at the very least, it would cause the underlying clients (in this case, java clients), to be processing a couple of meaningless events. Also, it would seem that the specified window manager key bindings are asking for the focus to be moved around to other windows in response to arrow keys, and that doesn't seem to happen (although if you are running in point-to-type mode, that's probably the right behavior). In any event, this window manager behavior triggers a behavior in awt whereby, when focus leaves the frame and then comes back, it is not always restored to the lightweight component that last owned it. Whether it is so restored or not depends on whether the focus loss was interpreted as a "permanent" or a "temporary" one. This interpretation is done using some heuristics in Solaris awt code; for example, the drag of a frame or the pulling down of a menu results in a temporary focus loss, because the events that report it have a detail of "WhileDragged" (or some such -- I don't remember exactly). In the case of the FocusOut event on the frame that results from whatever the window manager does in response to an arrow key press, the focus loss is interpreted as a permanent one, so that the FocusIn on the frame which follows immediately does not result in the restoration of focus to the lightweight that last owned it. What this means is that the subsequent arrow presses are being delivered to the wrong component. I am reassigning this to awt in case there is some way of making these FocusOut events into temporary focus losses (I rather doubt that there is, but I am no expert on this). But there also seems to be a window manager bug, in that these events don't have any business being generated in the first place. hania.gajewska@Eng 1999-02-09
09-02-1999