ListGrid Filtering Selection Bug

[chimpeenuts]

Using Smart GWT 3.0 nightlies. Power Version.

I ran into this UI drawing/refreshing bug while working on our project.

I was, however, able to recreate the bug using the Smart GWT client showcase example: http://www.smartclient.com/smartgwt/showcase/#grid_adaptive_filter_featured_category

Steps to reproduce:
1) ListGrid with:
setShowFilterEditor(true);
setFilterOnKeypress(true);
setFetchDelay(500);

2) Load all the data in the ListGrid. If the ListGrid is using paging, will need to scroll through the entire grid to make sure all data/records are loaded.

3) Use the mouse to select the first record in the grid. Now scroll to the last record and shift-click to select all the records in the grid. If an error says 'can't select all data or too much data' it means not all the data/rows have been loaded so need to re-scroll through the grid slower to make sure all the data gets loaded. If the grid doesn't use paging, should be able to select all rows with no error.

4) In the filter editor, enter a value that will filter some of the data (in the showcase example, enter 'pens' in the Item category).

5) Now select a **single** record returned in the filter results (in the showcase example, select the first visible record).

6) Now delete the value in the filter editor ('pens' in the showcase example).

7) Notice how all the data/rows re-appear but the previously hidden rows are still showing a selected 'style' while the rows that appeared during the filter that WERE NOT selected are unselected and the single row selected during the filter IS selected.

So the UI is showing rows that are selected, but the actual underlying ListGrid only says 1 row is selected.

I believe what needs to happen is that when a record is selected in a ListGrid during a Filter, all ListGrid records' styles need to be refreshed/updated even if they are not visible so that when they 'reappear' after the filter is cleared they have the unselected, default row styling.

Is there a known workaround to this issue?

[chimpeenuts]

As a follow up, I added a FilterEditorSubmit just to confirm that the # of selected records in the ListGrid does not match the number of records that 'appear' visually selected after clearing the filter:

_hostGrid.addFilterEditorSubmitHandler(new FilterEditorSubmitHandler() {

public void onFilterEditorSubmit(FilterEditorSubmitEvent event) {
	      System.out.println("# selected:" + _hostGrid.getSelectedRecords().length);
      }			
});

In my test case, after the listgrid is reshown with the invalid selection state, the output above is:

1

Which correctly matches the single record I selected while the grid was filtered but does NOT match the number of records I see selected in the UI.

[Isomorphic]

This seems like something that could only occur with a clientOnly DataSource, please confirm that's how you're reproducing it aside from the sample.

[chimpeenuts]

My listgrid is being populated from a SQL datasource.

It happens whether my listgrid is in paging mode (and I scroll to load all rows) OR if my listgrid is using:

_hostGrid.setDataFetchMode(FetchMode.BASIC);

Both cases exhibit the bug behavior.

Also, unless I'm mistaken, the Smart GWT showcase is *not* using a clientOnly DataSource. Perhaps I'm mistaken but this showcase example seems to be all about live, dynamic loading from a 'server'.

[chimpeenuts]

Perhaps what you meant in your initial response is that this happens when client-side filtering occurs. And that is indeed when this happens since once all the data in the listgrid is loaded, filtering uses client-side filtering.

I imagine if server-side filtering occurs and/or listgrid data is re-fetched from the server this issue may not arrise since the records fetched are new and obviously don't have the 'select' style applied to them so will appear as expected in the UI.

[Isomorphic]

Right, this is due to the listGrid.selectionProperty sticking on records that have been dropped from the current view but not form cache - whether that cache is the ResultSet, or the cache maintained by a clientOnly or cacheAllData:true DataSource.

We're looking at the best way to prevent this case of styling not matching the logical selection..

[chimpeenuts]

Well assuming all the data is cached on the browser/client side already (and is still part of the DOM), why not clear the 'selected' style attribute from all grid records regardless of whether they are visible or not when another row/record is selected?

Then when the rows are reshown after clearing the filter they will match the logical selection?

[chimpeenuts]

Has any progress been made on this issue?

Is the 'styling' of the UI now matching the logical selection?