TouchScrollStrategy.prototype.getScrollTop returns a wrong value...

[Martin Kleinschrodt]

... if the scroller is currently not in motion (isScrolling returns false) and the scroller is in overscroll. This causes problems if the scrollTop property of the scroll math is set to something greater than 0. I am curious why in the getScrollTop method of the TouchScrollStrategy kind the call is delegated to the super kind if the scroller is currently not scrolling. (https://github.com/enyojs/enyo/blob/master/source/touch/TouchScrollStrategy.js#L249). The ScrollStrategy kind returns this.scrollNode.scrollTop which is not the correct value if the scroller is in overscroll, since the TouchScrollStrategy uses a css transform to achieve negative scrollTop values. Simply returning this.scrollTop would solve the problem but I'm sure there is a reason for the current implementation.

I realize this is a corner case but I need this resolved. In case you're curious what I need it for: I am implementing a mixin for the Scroller kind that enables pull-to-refresh functionality and this requires setting the topBoundary of the scroll math to values other than 0. This means that the scroller can come to rest at a negative scrollTop value. In this case, calling getScrollTop will return an incorrect value - 0 - for the reasons described above.

So, long story short: Can anyone think of a reason why the line

return this.isScrolling() ? this.scrollTop : sup.apply(this, arguments);

can not be replaced with

return this.scrollTop;

Thanks,

Martin

[Ben Combee]

I think the reason for the delegation was to make overscroll transparent for users like enyo.List that want to do content generation based on the current position; for them, having a getScrollTop that returned negative values might cause problems.

So, in your case, I wonder if we need a separate API to present the actual scroll state instead of the content-oriented value.

Interesting idea with the pull-to-refresh mixin -- so it would be like the AroundList, but applicable to non-List contexts.

--
You received this message because you are subscribed to the Google Groups "Enyo Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to enyo-developme...@googlegroups.com.
To post to this group, send email to enyo-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/enyo-development/80047175-3a03-4a4e-9c87-7d0bdb53fc53%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Martin Kleinschrodt]

I don’t see why the scroller kind should not be allowed to return negative scrollTop values. Instead, users of the kind should be aware of the possibility of negative scrollTop values and handle those cases appropriately. It seems unnatural for the scroller kind to suppress the actual value and even more so if this happens only under specific circumstances (i.e. if the scroller is not currently scrolling). Moreover, ScrollStrategy.prototype.getScrollTop will also return negative values if native touch scrolling is used (e.g. via ‘-webkit-overflow-scrolling: touch’).

As for the pull-to-refresh mixin: I think it certainly makes sense to make pull-to-refresh a feature of the scroller kind rather than the list kind. I can think of several scenarios where I might like a pull-to-refresh functionality without having to use a list or data list. This is one of the reasons why I have found myself reimplementing pull-to-refresh on several occasions. By making pull-to-refresh a part of scroller (either directly or via a mixin) it could also easily be made available to the list kind via the scrollerOptions property. This becomes even more useful now that we have more than one list implementation (whats the deal with that, anyway?). 

You received this message because you are subscribed to a topic in the Google Groups "Enyo Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/enyo-development/JOS3TA5q01I/unsubscribe.
To unsubscribe from this group and all its topics, send an email to enyo-developme...@googlegroups.com.

To post to this group, send email to enyo-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/enyo-development/CAPG%2BkUPGiQTUBk5dKJeKgjuGqqT7RyWxAimFnTN%3DcL%2BB46MRpg%40mail.gmail.com.