JDK-4274963 : Typing into a JTable cell fails to transfer focus to the cell (cf. 4256006)
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.2.0,1.2.2
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,windows_nt
  • CPU: generic,x86
  • Submitted: 1999-09-23
  • Updated: 2001-04-02
  • Resolved: 2001-04-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
1.4.0 betaFixed
Related Reports
Duplicate :  
Relates :  

Name: krT82822			Date: 09/23/99

This is in response to the evaluation of bug 4256006. In spite
(or because) of what the evaluation said, I remain convinced that
this is a bug.

(I have included the bug report below, with the test case.)

The evaluator asks: "That's really the design here, if you have
ideas for a better design please send it in "

Okay, here goes. I propose you use the existing design. If I
edit a cell using the code below, and double-click into the cell.
You now get a focussed cell, with a blinking caret, into which
you can type. If you hit an arrow key, the cursor moves. The
selected cell doesn't change.

That's the design. Tha's also the behavior I want to see, and
it's already implemented. However, if you follow the instructions
described below, you get entirely different behavior, which is
clearly a bug.

What you get is a cell that appears to have the focus (it has a
black outline) and into which you can type, but the caret doesn't
blink. Once I start to type, I want to see exactly the same
behavior that I see if I double-click into the cell. The fact
that I can get two different behaviors when I enter text is
clearly a bug.

It is also unquestionably a bug when I can type without a caret.
My users are complaining about this issue. If you have any doubts,
or if you would like to discuss this issue with me, please call
me at 626/685-5661. I have submitted this bug three times before,
and it sometimes gets accepted, then closed with an evaluation
that fails to address the issue of the missing cursor. It's very
frustrating to submit the same bug over and over again.

Here is the original report.

Program to illustrate the caret bug.

Typing into an unfocussed cell fails to transfer the focus to
the cell editor.

  To reproduce, run this program. Click into any cell a single
time. A caret will not appear. At this point, the cell has a
colored outline, indicating that the JTable has the focus,
rather than the cell editor. So the caret should not be
visible yet.

Now, start typing. The cell outline will change to black,
indicating that the focus has shifted to the cell editor.
The text will appear as I type, but the caret is still
missing. By now, it is clear that there is a bug.
The caret should always be visible during typing.

It appears that, even though the cell is outlined in black,
and I can type into the cell, it still doesn't have the focus.
You can see this by hitting an arrow key. The focus will move
to a different cell, rather than changing the caret position.
This shows that the cell editor doesn't actually have the
focus, as it should.

Once I have started typing, I can click into the cell, and the
caret will finally appear. Now the arrow keys will move the

This behavior is discussed in bug 4188907. That bug was
erroneously closed. Please reopen that bug, rather than
creating a new bug. I don't want to lose the votes this bug
has already accumulated.


import javax.swing.*;
import javax.swing.event.*;
import javax.swing.table.*;
import java.awt.event.*;

public class JTableFocusBug
public static void main(String[] args)
JFrame mf = new JFrame("Caret in JTable Bug");
WindowListener wl = new WindowAdapter()
public void windowClosing(WindowEvent evt) { System.exit(0); }
mf.setBounds(10, 10, 400, 400);

JScrollPane scroller = new JScrollPane(new JTable(new BugModel()));

private static class BugModel extends AbstractTableModel
public int getRowCount() { return 3; }
public int getColumnCount() { return 3; }
public Object getValueAt(int row, int col) { return "" /* + row + ", " + col*/; }

BugModel() { super(); }

public boolean isCellEditable(int row, int col)
return true;
(Review ID: 95618) 

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: generic merlin-beta FIXED IN: merlin-beta INTEGRATED IN: merlin-beta

EVALUATION In Merlin-beta we have added a new property to the JTable: "surrendersFocusOnKeystroke" to address this issue. The property is false by default so the behavior of the JTable is backward compatible with previous releases. By setting the property value to true, the JTable is put in a mode where typing in a cell transfers focus to the editor automatically. The key difference in this mode is seen in the the behavior of horizonatal arrow keys which will effect intercell movements instead of changing the selected cell in the JTable. The blinking caret is also visible in this mode as the editor component has genuinely recieved the focus after a key is pressed. philip.milne@eng 2001-03-28