Top / bottom whitespace

[p-grzelczak]

We're having an issue with ui-scroll used with asynchronous calls. While scrolling some way to the bottom, then going back to the top and so on - there's always some whitespace at the top - sometimes really small, sometimes super huge. Sometimes it also appears on the bottom, but that's mostly noticeable with smaller datasets.

There's also a side issue with it (that may be related) in a console where we're logging descriptor state - notice how on first load console spits out descriptor.index with a value of 1, then 11 and then -9 - why is that negative? Why not 21?

Plunker with simplified test case below - try scrolling a bit to the bottom, then back to the top, then some more / less to the bottom, then back to top etc. There will be randomly sized white space up top most of the times (like this: http://i.imgur.com/8BXZFOD.png). We're using some placeholder API in there, feel free to fiddle with that - any help would be appreciated, as we're completely stuck with that for some time now.

https://plnkr.co/edit/GCm3a1a9iZOqkKrSA4sb?p=preview

We're using 1.5.0 ui-scroll in the example (although it's exactly the same with 1.4.x and 1.3.x versions)

Thanks in advance!

[dhilt]

This is definitely relates to #58 issue. If you just could switch your api logic from pages to index-offset, the problem will vanish. If it's not acceptable for you, on 4th comment you may obtain a workaround.

The point is that the process of invisible items clipping does not relate to the buffer-size attribute, it relates to the padding attribute and item heights. So during scrolling up after some rows were clipped from the top of the viewport, the ui-scroll is still trying to retrieve "buffer-size" items but the start index of such request is not multiple of buffer-size... So the page = Math.ceil(descriptor.index / descriptor.count); computation becames not valid.

[mrova]

Thank you @dhilt.

P.S.
Sorry for providing this example so late!

[javagrrl42]

I'm having this issue as well, and I am using index and offsets. I was looking at the minIndex example and I see the problem there as well. Once you scroll down a bit, then quickly scroll up, there is a big white space at the top. I'd be okay with this if I could insert a list item (that says 'loading') that only shows when adapter.isLoading == true, but I haven't had much luck with this. But back to the point at hand - I have set the buffer size to 50 and always pull 50 items from the back end, but I am still getting requests to the datasource get method with indices that are not multiples of 50. If fixing this will fix my whitespace problem, then I would love to hear how I can enforce this. Thank you!

[mrova]

Here's working example with offset/limit API: https://plnkr.co/edit/uk9QOq752CtYMmrM1rkK?p=preview

@javagrrl42, please verify if you're using the latest version. It was fixed in version 1.4.0 I guess.

[javagrrl42]

@mrova Thanks for the example; it's helpful. I've slowed it down in plunker by putting in a timeout in the 'then' function of dataSource.get(). When first loading, the list does behave nicely, with the loading img showing up as expected. However, after scrolling up and then down again, it's easy to reproduce the situation where the loading image shows up after a large white space. This is the only code change I made:
}).then(function(response) {
console.log('success:', response)
setTimeout(function() {
return success(response.data);
}, 1000);

However, I also tried adding the loading item at the top of the list, just to see if it might have any bearing on the bottom white space, like so:
open - li ng-if="adapter.isLoading && adapter.prepend" class="spinner"
img src="http://preloaders.net/preloaders/712/Floating%20rays.gif"
close -li
The same problem - a large gap between the loading image and list - can be seen here as well.

[Jerczu]

@p-grzelczak @mrova See I had similar issues when you quick scroll up and down at the bottom of the scrollview often I had massive white space. Since it's a very particular problem as it literally applies only to my app I edited the library source and force zeroing on paddings. So in the adjustPadding method in adapter I added at very bottom
if(buffer.eof){ bottomPadding.height(0); }
Works like a charm I never have wrong padding on my chat anymore and ajax inserted content don't cause it to resize to ridiculous sizes. I am assuming you can do similar changes and check buffer.bof and buffer.eof and adjust relevant paddings accordingly.

[dhilt]

@Jerczu It sounds like https://github.com/angular-ui/ui-scroll/pull/173/files try. I see there may be some edge cases affected... Recently I made some fix for scroll top process around that piece of logic, and is it's possible, I would ask you to

• try effective-height branch distributive https://github.com/angular-ui/ui-scroll/blob/effective-height/dist/ui-scroll.js in your project;
• give a simpliest repro of the issue, for I could investigate it thoroughly.

Thanks!

[Jerczu]

Yeah no problem I give it a whirl.

[Jerczu]

@dhilt so I used the effective-height branch clipping works quite nice but I think there's a bug on clipping. Namely when you use scroll for chat. I might not explain it well but the problem happens if you keep constantly appending messages. The dataserver expects the negative offsets so when it starts the first page has offsets -19 and 0 and 2nd page -38 and -20. Now start appending messages to the dataset with each append the offsets start to reduce and at certain point turn into positive values which then completely screws the pagination. I had to add the

if(buffer.first > 1){ buffer.first = 1; }
to the clipTop of the viewport class in the block if(overage > 0) to preserve the -19 and 0 start values.

[Jerczu]

Like I said I kinda heavily editied your library to fit my purpose but I am guessing this is a side effect as positive negative offsets would screw with your dataset displaying.

[dhilt]

@Jerczu Looks like this is the datasource implementation issue or server side pagination issue. Need to see the code... I also believe that if it's the component's problem, then it could be reproduced on a simpler sample (not only chat).

[dhilt]

Despite the issue is resolved partially, it is closed due to inactivity.