happens if (super) startEdit didn't succeed (== !cell.isEditing)
- must not fire editStart event
- must not update control's editing location
failing tests for ListCell (each failing on the last assert):
@Test
public void testStartEditOffRangeMustNotFireStartEdit() {
list.setEditable(true);
cell.updateListView(list);
cell.updateIndex(list.getItems().size());
List<EditEvent> events = new ArrayList<>();
list.addEventHandler(ListView.editStartEvent(), events::add);
cell.startEdit();
assertFalse("sanity: off-range cell must not be editing", cell.isEditing());
assertEquals("must not fire editStart", 0, events.size());
}
@Test
public void testStartEditOffRangeMustNotUpdateEditingLocation() {
list.setEditable(true);
cell.updateListView(list);
cell.updateIndex(list.getItems().size());
cell.startEdit();
assertFalse("sanity: cell must not be editing if index off range", cell.isEditing());
assertEquals("editing location", - 1, list.getEditingIndex());
}
for list, it sets the editingIndex to the off-range value. For tree-/table, a fix ofJDK-8187474 leads to a stackoverflow error. Tree not yet tested, probably similar.
Problem seems to be the implementation pattern of startEdit (which is basically the same for all concrete cells)
// backout if not editable for any reason
if (notEditable ...) return;
// note: null control and/or other related parties is allowed
super.startEdit();
if (eventTarget != null)
fire(editStart)
if (editingControl != null)
editingControl.edit(cellLocation)
that is, both firing and updating control's state will happen even if the cell is not in editing state.
Checking EditEvent spec: listView.setOnEditStart
"the EventHandler that will be called when the user begins an edit" implies (for me at least ;) that the edit actually _did_ start.
Fix would be to backout if cell is not in editing state after calling super (just as the really editable cells in the xx.cell package are doing, seeJDK-8188026):
....
super.startEdit();
if (!isEditing()) return;
...
P3 because it blocksJDK-8187474
- must not fire editStart event
- must not update control's editing location
failing tests for ListCell (each failing on the last assert):
@Test
public void testStartEditOffRangeMustNotFireStartEdit() {
list.setEditable(true);
cell.updateListView(list);
cell.updateIndex(list.getItems().size());
List<EditEvent> events = new ArrayList<>();
list.addEventHandler(ListView.editStartEvent(), events::add);
cell.startEdit();
assertFalse("sanity: off-range cell must not be editing", cell.isEditing());
assertEquals("must not fire editStart", 0, events.size());
}
@Test
public void testStartEditOffRangeMustNotUpdateEditingLocation() {
list.setEditable(true);
cell.updateListView(list);
cell.updateIndex(list.getItems().size());
cell.startEdit();
assertFalse("sanity: cell must not be editing if index off range", cell.isEditing());
assertEquals("editing location", - 1, list.getEditingIndex());
}
for list, it sets the editingIndex to the off-range value. For tree-/table, a fix of
Problem seems to be the implementation pattern of startEdit (which is basically the same for all concrete cells)
// backout if not editable for any reason
if (notEditable ...) return;
// note: null control and/or other related parties is allowed
super.startEdit();
if (eventTarget != null)
fire(editStart)
if (editingControl != null)
editingControl.edit(cellLocation)
that is, both firing and updating control's state will happen even if the cell is not in editing state.
Checking EditEvent spec: listView.setOnEditStart
"the EventHandler that will be called when the user begins an edit" implies (for me at least ;) that the edit actually _did_ start.
Fix would be to backout if cell is not in editing state after calling super (just as the really editable cells in the xx.cell package are doing, see
....
super.startEdit();
if (!isEditing()) return;
...
P3 because it blocks
- blocks
-
JDK-8187474 Tree-/TableCell, TreeCell: editingCell/Item not updated in cell.startEdit
- Resolved