Search code, repositories, users, issues, pull requests...

The story of inline and float-left elements is still not over.
Just run this demo and try to scroll up.

mentioned this

on Jul 20, 2015

Problem scrolling up with multiple items per row Hill30/NGScroller#93

added 2 commits that reference this issue

Contributor

@SaintFlipper can you check if this fixes your issue?

Hi, the new #8 seems to change the behaviour but not quite fix it:
a) It still results in duplicate items when scrolling back to the top (see image)
b) Usually it doesn't allow scrolling back to item 1, as shown in the image where item 7 is as low as it goes. It's not clear what the circumstances are for this, but making the results frame 6 items wide in http://jsfiddle.net/mn59dvjn/7/ seems to allow this to be reproduced.

c) Having said that, in my real-world code (not stand-alone) it's improved as it consistently allows scrolling back to item 1, but still shows the same "bouncing" behaviour where it alternates between requesting low and high item regions; here are the last few item requests when scrolling up:

data source get : index=10, count=10
data source get : index=62, count=10
data source get : index=7, count=10
data source get : index=59, count=10
data source get : index=4, count=10
data source get : index=56, count=10
data source get : index=1, count=10
data source get : index=53, count=10
data source get : index=-2, count=10
data source get : index=50, count=10

By the way, is there a version identifier in ui-scroll that can be queried or seen in the source? It's difficult to be sure that the latest version is being loaded (and the older version isn't being cached in a real-world case).

MemberAuthor

@SaintFlipper
I've forked your fiddle and tuned the edge cases logic within your controller:
http://jsfiddle.net/q4xstonz/
It seems that the duplicate issue is gone.

@mfeingold But what I really dislike is that the scrollbar heigth is being recalculated incorrectly (during scroll-up) and there is no chance to scroll to the top of the list (long enough list I mean) from the very bottom without additional clicking...

Thanks for that; my previous logic for handling out-of-range items explains the different behaviour of the stand-alone case, but not the "bouncing range" data source request or the difficulty scrolling to the top of the list which you mention. I suspect those symptoms are related. Have you looked at the console to see the data source requests which the JSfiddle data source sees? Below is what I see with a 6-image wide results pane. As you scroll upwards the data source sees alternate low & high range requests which I think garbles the display. For example as you initially scroll down the leftmost item number moves up in multiples of 6 (1,7,13,19...) as expected, but when scrolling up it jumps around almost randomly.

Eventually the display sorts itself out when it reaches item 1, but it doesn't look right until that point.

12:07:22.163 "data source get : index=1, count=10"      // Initial load
12:07:22.235 "data source get : index=11, count=10"
12:07:22.478 "data source get : index=21, count=10"
12:07:22.573 "data source get : index=31, count=10"
12:07:22.697 "data source get : index=41, count=10"
12:07:22.800 "data source get : index=-9, count=10"
12:07:28.389 "data source get : index=51, count=10"     // Scrolling down starts here
12:07:28.762 "data source get : index=61, count=10"
12:07:29.611 "data source get : index=71, count=10"
12:07:30.976 "data source get : index=81, count=10"
12:07:31.142 "data source get : index=91, count=10"
12:07:34.372 "data source get : index=101, count=10"
12:07:35.775 "data source get : index=45, count=10"     // Scrolling up starts here
12:07:35.833 "data source get : index=103, count=10"
12:07:35.972 "data source get : index=41, count=10"
12:07:36.031 "data source get : index=99, count=10"
12:07:36.386 "data source get : index=37, count=10"
12:07:36.617 "data source get : index=95, count=10"
12:07:37.189 "data source get : index=27, count=10"
12:07:37.408 "data source get : index=67, count=10"
12:07:37.524 "data source get : index=17, count=10"
12:07:37.619 "data source get : index=69, count=10"
12:07:37.807 "data source get : index=7, count=10"
12:07:37.850 "data source get : index=65, count=10"
12:07:38.413 "data source get : index=-3, count=10"     // Displays item #1 here
12:07:38.706 "data source get : index=61, count=10"

Contributor

I believe we know the root cause of the problem. will have a fix shortly

On Sat, Aug 1, 2015 at 6:34 AM, SaintFlipper notifications@github.com
wrote:

Thanks for that; my previous logic for handling out-of-range items
explains the different behaviour of the stand-alone case, but not the
"bouncing range" data source request or the difficulty scrolling to the top
of the list which you mention. I suspect those symptoms are related. Have
you looked at the console to see the data source requests which the
JSfiddle data source sees? Below is what I see with a 6-image wide results
pane. As you scroll upwards the data source sees alternate low & high range
requests which I think garbles the display. For example as you initially
scroll down the leftmost item number moves up in multiples of 6
(1,7,13,19...) as expected, but when scrolling up it jumps around almost
randomly.

Eventually the display sorts itself out when it reaches item 1, but it
doesn't look right until that point.

12:07:22.163 "data source get : index=1, count=10" // Initial load
12:07:22.235 "data source get : index=11, count=10"
12:07:22.478 "data source get : index=21, count=10"
12:07:22.573 "data source get : index=31, count=10"
12:07:22.697 "data source get : index=41, count=10"
12:07:22.800 "data source get : index=-9, count=10"
12:07:28.389 "data source get : index=51, count=10" // Scrolling down starts here
12:07:28.762 "data source get : index=61, count=10"
12:07:29.611 "data source get : index=71, count=10"
12:07:30.976 "data source get : index=81, count=10"
12:07:31.142 "data source get : index=91, count=10"
12:07:34.372 "data source get : index=101, count=10"
12:07:35.775 "data source get : index=45, count=10" // Scrolling up starts here
12:07:35.833 "data source get : index=103, count=10"
12:07:35.972 "data source get : index=41, count=10"
12:07:36.031 "data source get : index=99, count=10"
12:07:36.386 "data source get : index=37, count=10"
12:07:36.617 "data source get : index=95, count=10"
12:07:37.189 "data source get : index=27, count=10"
12:07:37.408 "data source get : index=67, count=10"
12:07:37.524 "data source get : index=17, count=10"
12:07:37.619 "data source get : index=69, count=10"
12:07:37.807 "data source get : index=7, count=10"
12:07:37.850 "data source get : index=65, count=10"
12:07:38.413 "data source get : index=-3, count=10" // Displays item #1 here
12:07:38.706 "data source get : index=61, count=10"

—
Reply to this email directly or view it on GitHub
#8 (comment).

Contributor

@SaintFlipper @dhilt guys, can you try it again? I think I eliminated the jumping. Can you confirm?

MemberAuthor

A new issue was found (https://www.youtube.com/watch?v=xwjupzIwQXA). We are going to fix it and cover it with tests. The 1.3.1 release is comming soon.

MemberAuthor

The 1.3.1 version is released (#12).
And now you can also obtain the release data from js-sources.

closed this as completed

on Aug 5, 2015

marknadig

Contributor

@dhilt @PowerKiKi is there a manual step to publish this to npm, or is it a timing issue? Not seeing 1.3.1 out there. Thank you.

I'm not seeing a big difference from the previous version. Using http://jsfiddle.net/q4xstonz/1/ and with the results pane 6 items wide I still see the "bouncing data source range" behaviour (see below log) and the leftmost displayed item number doesn't follow the expected sequence when scrolling upwards (ie. not 1 + 6N where N is the row number).

Can I ask again whether there's some way to query the ui-scroll version number, or at least to see the version number somewhere in the source? It's not obvious by viewing the js source that the latest ui-scroll is being used.

data source get : index=1, count=10  // Initial load
data source get : index=11, count=10
data source get : index=21, count=10
data source get : index=31, count=10
data source get : index=41, count=10
data source get : index=-9, count=10
data source get : index=51, count=10  // Scrolling down
data source get : index=61, count=10
data source get : index=71, count=10
data source get : index=81, count=10
data source get : index=91, count=10
data source get : index=101, count=10
data source get : index=111, count=10
data source get : index=121, count=10
data source get : index=63, count=10     // Start of scrolling up
data source get : index=121, count=10
data source get : index=59, count=10
data source get : index=117, count=10
data source get : index=55, count=10
data source get : index=119, count=10
data source get : index=51, count=10
data source get : index=115, count=10
data source get : index=47, count=10
data source get : index=117, count=10
data source get : index=43, count=10
data source get : index=113, count=10
data source get : index=39, count=10
data source get : index=115, count=10
data source get : index=35, count=10
data source get : index=111, count=10
data source get : index=31, count=10
data source get : index=113, count=10
data source get : index=27, count=10
data source get : index=109, count=10
data source get : index=23, count=10
data source get : index=111, count=10
data source get : index=19, count=10
data source get : index=107, count=10
data source get : index=15, count=10
data source get : index=109, count=10
data source get : index=11, count=10
data source get : index=105, count=10
data source get : index=7, count=10
data source get : index=107, count=10
data source get : index=3, count=10
data source get : index=103, count=10
data source get : index=-1, count=10  // Back to item no. 1

PowerKiKi

Contributor

@marknadig packages are published automatically by Travis as soon as a tag is pushed. This was not the case for v1.3.1, because we explicitly told Travis to ignore tags. It is now fixed via 89bc6fc. Meanwhile I published v1.3.1 manually and it is now accessible.

12 remaining items

stnash

Agreed, I see that same issue still as well. But at least it's one step closer ;-)

I found a solution for this problem which works with the latest version 1.3.2.
The Trick is to let the datasource map the requested index and count to internal values and the result should be mapped to reflect the desired structure. Which means, if if I want to display 2 items per line, I will multiply each index - 1 (to make it zero based) and count that is requested at the datasource.get method with 2. So if index is 1 and count 3 the returned array of the datasource looks like this:

[
  [item1, item2],
  [item3, item4],
  [item5, item6]
]

The scroll view then handles the requested 3 items while 6 are displayed in reality, just view has to be updated to handle the new data structure.
I didn't notice any scroll glitches so far. If someone is interested I can update one of the previous fiddles with an example.

Hi Matthias

That's a very useful observation, which hopefully might help the developers
find a longer term solution to this problem.

It would be helpful if you could update the JSfiddle with your workaround,
as I'm not completely clear on your explanation - are you suggesting that
if get() receives a count of X items then it should return X_N contiguous
items, where N is the number of items per row ? Or are you also saying that
the item index is also multiplied by N, so, for example rather than
querying items 1,2,3 you would query items 1,3,5,7,9,11 ? I created a quick
test case assuming 4 items per row, returning X_4 contiguous items for each
request, but I see duplicate items in the list, so maybe I'm
misunderstanding your explanation.

One drawback with this workaround is that from your explanation it seems
that get() needs to know how many items per row are being displayed. In the
case of a resizeable DIV with float:left items that will be variable, and
there would need to be a calculation to determine the count of items per
row, which would have to take into account the item styling (borders,
padding, margins etc).

On 14 October 2015 at 14:02, Matthias Tylkowski notifications@github.com
wrote:

I found a solution for this problem which works with the latest version
1.3.2.
The Trick is to let the datasource map the requested index and count to
internal values and the result should be mapped to reflect the desired
structure. Which means, if if I want to display 2 items per line, I
will multiply each index - 1 (to make it zero based) and count that is
requested at the datasource.get method with 2. So if index is 1 and
count 3 the returned array of the datasource looks like this:

[
[item1, item2],
[item3, item4],
[item5, item6]
]

The scroll view then handles the requested 3 items while 6 are displayed
in reality, just view has to be updated to handle the new data structure.
I didn't notice any scroll glitches so far. If someone is interested I can
update one of the previous fiddles with an example.

—
Reply to this email directly or view it on GitHub
#8 (comment).

Everything is multiplied with N.
My explanation was more focused on my use case where I have ajax requests in my datasource, there I don't need add the index to the count.
Anyway here is a fiddle: http://jsfiddle.net/q4xstonz/17/. The only important things there are buffer-size and itemsPerRow. Hope it helps

Yes the drawback is that you have to know the items per line. But that can be fixed or has to be calculated.

The problem with the jumping around with dynamic items per line is that the scroller expects 10 items (buffer-size=10) which results in a height of the content area of 10 * itemHeight, but the real content area height is 10 * itemHeight / itemsPerLine. So when you scroll and new Items are added the scroll position is also adjusted, which results in jumping around as the real and the calculated positions don't match, because the scroller can not know how many items there are per line. The expectation is one.

hornetnz

Your fiddle isnt working tylkomat.

It's working for me. What is not working for you?

hornetnz

I had to change the ui-scroll js link to rawgithub.com. It gave an error otherwise.

batista

any updates on this one? am trying to follow up on @tylkomat fiddle, but with 8 elements per row. it works ok-ish, but if i keep scrolling the second time it loads, it will roll back up the scroll and start from the top. check the fiddle here

@batista your algorithm is off, the first line has only three items, if you put a clear on the div with the ui-scroll directive, you will see what I mean. Anyway you need that, the lines should not mix. If you have six lines they should be six lines on any screen and not 4 on a large and 10 on a small. Otherwise it messes with the continuous scroll detection of ui-scroll.

As for the jumping back and forth I also don't have an idea.

batista

@tylkomat thanks! i was fiddling with yours and forgot to update the if condition for the push to temp array.

here's the updated (and more dynamic) way: if (i % itemsPerRow === itemsPerRow - 1) {

also updated fiddle here where the itemsPerRow var works as expected.

Contributor

This is a slippery one. My next big idea was to refactor all functions replacing code relaying on height to relay on positions, Unfortunately at the moment I do not have the bandwidth to deal with this. Any volunteers?

gjwilk01

Any plans to address the backward scroll issue discussed in this topic? Any good workarounds?

Thanks in advance!