The second (and all subsequent) setSelection on a filtered virtual TableViewer selects the wrong row/entry

[jfuerter]

We have a (SWT.VIRTUAL) TableViewer and in certain constellations the second and all subsequent setSelections select the wrong entry.

1. Create a (SWT.VIRTUAL) TableViewer (new LabelProvider(), ArrayContentProvider.getInstance())
2. Add 100 entries to the table with TableViewer.setInput
3. TableViewer.setSelection to the 4th entry (referring to the original input)
4. The correct entry is selected
5. Now add a filter to the TableViewer so that only the 3rd, 4th, 5th and 6th entries (referring to the original input) are left
6. TableViewer.setSelection to the 4th entry (referring to the original input)
7. Now: From the resulting 4 rows the second row should be selected, instead the 6th is selected
8. The Problems occurs because Step 5 executes a "clear" on all TableItems but this clear keeps the Widget.data field value intact and the original 4th items seems to be recycled for the new 6th item. So when Step 6 searchs for a matching Item it finds the wrong TableItem by comparing the 'new Selection' with the TableItem.getData (method from Widget)

Here a simple project to reproduce the issue:
https://we.tl/t-s0uMT7MLpG

(edit 2022-09-29 @mknauer: Attached referenced ZIP archive as Issue 57.zip to this issue)

Just open the web app and watch the Console. I've tried to keep the project as simple as possible (no fancy code) and to describe the problem with the comments within the code and in the console output. All the relevant code is in the class View.

I've fixed the issue by extending the clear method on TableItem but I don't know if this is a valid fix but would result in other problems:

    final void clear() {
        data = null;
        checked = false;
        grayed = false;
        parent.updateScrollBars();
        if ((parent.style & SWT.VIRTUAL) != 0) {
            cached = false;
            setData(null);  // <= added this line
            parent.redraw();
        }
    }

Attention: The described fix does NOT work with TableViewer.setUseHashlookup(true)!

[jfuerter]

The linked project should be available for about 3-4 more days. If it's gone please write a message and I'll upload it again.

[mknauer]

I retrieved the ZIP archive from the link in the initial bug report and attached it here as Issue 57.zip.