Issue with blank rows in listgrid

[rn]

Hello,

Our users have reported an issue with the list grid where one or more rows sometimes disappears in the bottom while scrolling in the list grid. The rows are completely blank, but hover/tooltip still shows the correct value. We have only been able to reproduce the problem with one row disappearing, but our users report that up to 3 rows can disappear.
We have been fiddling with the values of the drawAheadRatio, but it does not seem to fix the issue. Setting showAllRecords also does not solve the issue and is also not feasible since the grid contains a lot of rows (~1000-1500).

The issue has been reproduced on latest Safari, latest Chrome and Internet Explorer 11 on both Windows and Mac. I have linked to a screen recording where the issue is reproduced in the SmartGwt showcase.
https://www.dropbox.com/s/o9n8on0p0dz5jyv/grid.mov?dl=0

Is this a known issue and are there any workarounds?
Hope you can help.

Best Regards
Rasmus

[Isomorphic]

Hi rn
We have reproduced and fixed the problem with a single row at the bottom of the viewport not being rendered. This fix will be in the next nightly build for both 13.1 and 12.1 branches.

We haven't yet been able to reproduce a case where multiple rows are not rendered. Given that it's not readily reproducible, this bug may be dependent on the settings for the grid itself -many properties such as fixed record heights, autoFit data, etc could subtly change things here.

If the fix we applied doesn't resolve this issue fully, and the "3 rows of blank space" issue persists, the best way to proceed would be to get a reproducible case to us.
We'd probably need to see the grid configuration - ideally in a standalone test case we can actually run - as well as details of which build this was seen on, which skin was loaded, and any OS / browser configuration you can share with us, including any custom zoom levels

Thanks
Isomorphic Software

[rn]

Hello,

That is very good news. We will test and deploy to our users. Hopefully it completely fixes the issue.
Thanks!

Best Regards
Rasmus

[rn]

Hi,

We have confirmed that the issue with a single blank row is fixed. However, our customer still reports the issue with multiple blank rows. Alas we are not able to reproduce the problem.
Would you be able to provide any pointers on how we can get our customer to provide the necessary data for creating a test case? What kind of information, would be needed to get from our customer.

Best Regards
Rasmus

[Blama]

Hi @rn,

just to be sure: Are you sure your users don't talk about the white *area* that can be there at the very end of the ListGrid because of virtual scrolling (see here)?

Best regards
Blama

[rn]

Hi Blama,

I am pretty sure that is not the case, since they can still hover the mouse above the blank area and see the hover/tooltip of the rows that are supposed to be there. I have attached a screenshot that shows the tooltip for the bottom row.

Best Regards
Rasmus

[Isomorphic]

This other case is almost certainly a browser bug, so let us know what browser(s) and platform(s) this is reproducible on. Also needed:

1. check using browser Developer Tools whether there are actually rows there in the blank space that the browser just isn't rendering (erroneously) or whether the DOM rows end where the browser stopped rendering

2. see what height the rows are and compare to your configured cell height. One possibility here is that browser bugs are simply causing the browser to render rows too short, so they don't fill the viewport as they should

3. take stock of a few times when it's happened and report to us the range of rows that are visible when it happens, and the total number of rows in the dataset. This could reveal whether the browser is making a cumulative error or doing something else

[rn]

Hello,

Thanks, I will try to investigate and collect further input.
I know out clients are using latest Chrome and Edge on Windows 10 - and I know that they do not see this issue in Internet Explorer.

Best Regards
Rasmus

[rn]

Hello,

I had a remote session with our client today and I gathered the following info.

When checking the DOM tree in the Chrome dev tools, there are NO table rows for the blank area. The last row (the last tr element) is also the last row that the user can actually see. That last tr item looks like:

<tr role="listitem" aria-setsize="246" aria-posinset="243">

There are suppose to be 246 rows in the list grid. When I test that is also the number of rows that I get, but for our client, they are always missing the last 3 rows.

After the table element there is a div element. For our client it looks like:

<div style="width:1px;height:60px;overflow:hidden;" id="isc_StationListGrid_1_body$284">
<span style="display:inline-block;background-size:100% 100%;background-image:url(&quot;[URL TO SMARTGWT RESOURCES]/Enterprise/images/blank.gif&quot;);width:1px;height:60px;vertical-align:text-top"></span>
</div>

This element is 60px in height, but when I check in my browser it is 0px in height. So, I guess this div is the culprit.

Cell height is set to 20px in code. When I check the td elements inside the tr rows, they are 20 (18 in height, 1px top border, 1px bottom border).

As mentioned earlier, our client can consistently reproduce this issue in latest Chrome and Edge on Windows 10 - but it does not happen in Internet Explorer.

Hope this information can help. Let me know if more info is needed.

Best Regards
Rasmus

EDIT: Also as mentioned earlier: when the user hovers the mouse above the blank area, the tooltip of the missing rows are showing.

[Isomorphic]

Thanks for the additional information.

If it's easy to get on the remote session again, could you see whether evaluating isc_StationListGrid_1.redraw() fixes things?
It's likely that this grid is somehow failing to redraw after a scroll completes, though we're not yet sure why this would occur. If this is the case the explicit call to 'redraw' would fix it.

One more thing that might help would be to look at the configuration of the grid itself.
If you evaluate "isc_StationListGrid_1" in the developer console, you should see the grid definition serialized out as a large block of JavaScript. If possible we'd be interested in seeing this definition. Rather than posting it on the public forums, you could send this to support@isomorhic.com.
We don't need to see any confidential information - the actual data or fields - but we'd be interested in top level settings like whether there are frozen fields, whether virtual scrolling or variable row heights are enabled, etc.

In the meantime we'll also investigate further on our end and see if we can determine what's special about the environments where this happens (Edge/Chrome on Windows 10)

Regards
Isomorphic Software

-----------------
EDIT:
One additional question - if you set the special enforceVClipping attribute on this grid, does the problem go away? While we still can't reproduce this problem on our end, we're guessing there may be an issue to do with rows rendering taller than expected due to the icons, and enforcing vertical clipping would certainly avoid that.

[rn]

Hi guys,

I have sent an email with the requested data.
The initial test with our client with redraw did not fix the problem.

We will continue to test with redraw and the enforceVClipping property, and get back to you.

Best Regards
Rasmus

[rn]

Hi,

We have just received feedback from our client and the enforceVClipping property seems to have fixed the issue.
Thank you very much for your help.

Best Regards
Rasmus

[rn]

Hi guys,

I just received news from a couple of our clients that this issue has returned. It seemed to have been fixed after adding the enforceVClipping property, but now they are experiencing the exact same problem again. Currently we think it is due to a browser update. The clients are running latest versions of Chrome (89.0.4389.128) and Edge (89.0.774.76) on Windows 10.

We are still not able to reproduce this problem in our tests.
Do you have any advice on how to proceed?

Best Regards
Rasmus

[Isomorphic]

Unfortunately, we still don't have a test case from you showing how it can be reproduced.

The first thing we'd check is whether, through some deployment issue, you might have accidentally reverted your workarounds, since the client reported the problem fixed.

Also, we would recommend testing with absolutely no CSS in the page other than that which ships with our product. The most likely cause is still something to do with that.