Openui5: sap.ui.table.Table: Threshold ineffective on initial load

[janmattfeld]

OpenUI5 version: 1.60.16 (possibly any other)
Browser: Chrome 76.0.3809.100 (Windows 10 x64 10.0.18362)
Any other tested browsers: Also fails in Edge and Internet Explorer 11
Minimal example: https://output.jsbin.com/manuqavuvu/1 (Disable CORS!)

Steps to reproduce the problem:

1. Use sap.ui.table

   • threshold = 500
   • visibleRowCountMode = Auto

2. Query a larger OData v2 data source

What is the expected result?

The table immediatly fetches data for the first 500 rows. Thus, enabling smooth scrolling through a large portion of these entries without further interruption as described in the API documentation for the threshold property.

What happens instead?

The table fetches additional data way to early, in some cases right after the first or second scrolling. During the fetch, the table's local busy indicator is displayed, preventing all user interaction. This becomes really annoying if the query actually takes time and blocks the user from scrolling through the remaining 80% of the already loaded data.

Network trace of the minimal example immediately after displaying the table:

1. GET Orders?$skip=0&$top=505 (Correct)
2. GET Orders?$skip=200&$top=500 (What now?)
3. GET Orders?$skip=400&$top=430 (No idea)

This might or might not be related to the OData test service. Yet, the symptoms are identical using on-premise SAP Gateway services.

[ThomasChadzelek]

Hello @janmattfeld !

I understand that you are using OData V2 and I cannot immediately help there. My team is doing OData V4. Nevertheless I would like to better understand your scenario. You say that the 2nd GET blocks the UI and prevents further scrolling? How does that look like for the end user; I mean, is there a wait cursor or what happens?

Best regards,
Thomas

[janmattfeld]

HI @ThomasChadzelek,

Thanks for your prompt reply.

The table switches into a local busy state, preventing all user interaction (showing the local busy indicator only). I updated my initial issue description.

Thanks,
Jan

[ThomasChadzelek]

Hello @janmattfeld !

Thanks for the clarification. Looks like we have a similar issue with V4. We will fix that, but my team cannot fix the V2 issue. I will see how I can help to dispatch this question.

Best regards,
Thomas

[janmattfeld]

Hi @ThomasChadzelek ,

did you have a chance to dispatch the issue?

Thanks,
Jan

[ThomasChadzelek]

Hello @janmattfeld !

Sorry that we did not respond for so long. Looks like I immediately dispatched the issue, but my colleague did not find the time to look at it so far. Good news it that Patric has now taken over and I trust him to take care. Stay tuned!

Best regards,
Thomas

[Jordan-Ryan]

Hi,

I am running on version: 1.60.24

I have a very similiar issue, on inital load it calls the service for 113 records (13 visible and 100 threshold) but when I scroll down (past the 13 records) it starts to call the service again, meaning the busy indicator comes and the table is not usable.

Would this be the same issue as mentioned here or would this be slightly different?

[janmattfeld]

That sounds like the exact same issue. Thanks for sharing!

[Jordan-Ryan]

That sounds like the exact same issue. Thanks for sharing!

Thanks. Mine isn’t doing the issue where the threshold changes though. So skip and top seem fine. So it then goes skip 113 top 100 skip 213 top 100. Which is why i asked if it was covered under the same bug.

Is there any solution for this I’m thinking maybe on before rebind table. We can quickly close the busy indicator and the table state. That way it fetches the next 100 when its 100 away (hopefully then when the user gets there its already loaded). Only issue then, is if they use the scroll bar it wont be very intuitive to show its loading data.

[janmattfeld]

_top_ and _skip_ are not my main concern, though. What bothers my users most, is activating the busy indicator too soon, while there are still records that could be shown.

I disabled the local table busy indicator completely. That seems to be the same effect your event listener to rebinding would do, right? But that of course leads to awkward situations, when the next data is loading but on the UI nothing seems to happen.

So, the fix should probably be UI5-internal, as all workarounds to this point failed.

[Shtilianova]

Hello @janmattfeld ,
I've created an internal incident 2080375757. The status of the issue will be updated here in GitHub.
Regards, Diana

[karm31]

@Shtilianova Hi any update on this issue? I am facing the same issue,

Regards
Karm

[uhlmannm]

Hi,

unfortunately, the issue could not be resolved so far. We are internally tracking this as FIORITECHP1-6587.

Best regards
Mathias.