[ScrollView] Scrolling ends prematurely in ScrollViews embedded in a parent ScrollView

[jordanna]

You can see this behavior in the UIExplorer app's <ScrollView> example. Fling to initiate a scroll in an inner ScrollView and fling again (before scrolling ends) to increase scroll momentum. Often times, this causes the scrolling to stop.

I haven't had gone through all of the ResponderEventPlugin code yet, but I'm seeing that when ResponderEventPlugin.extractEvents is called, the topLevelTargetID is sometimes incorrect.

The touches that unintentionally stop scrolling appear to be associated with the parent ScrollView instead of the inner ScrollView's content. I traced this down to RTCScrollView._shouldDisableScrollInteraction where [self isDescendantOfView:JSResponder] is sometimes YES. Forcing it to always return NO fixes the issue, but I'm pretty sure that's not the intention of this method :)

[vjeux]

Cc @jordwalke

[jordwalke]

Great investigation, @jordanna. The information is very helpful. Scroll views in native know to stop scrolling if something that contains them becomes the responder in JS (like if you were dragging an outer modal view down - that should stop any scroll views from scrolling). My question is, why is the outer scroll view becoming the JS responder? One thing that would cause this is an onScroll occurring on the outer scroll view.
(This is why I just wish all the scroll views were implemented in JS - all these problems go away).

[jordanna]

Ok, I finally got around to looking more into this issue (was sidetracked by animation hacks!). During event extraction in the ResponderEventPlugin, I'm seeing JS responder being transferred from the inner scroller to the outer on a topScroll event.

function setResponderAndExtractTransfer(
    topLevelType,
    topLevelTargetID,
    nativeEvent) {

  // topLevelType === 'topScroll'
  // topLevelTargetID === ID of inner scroller
  ...

  // bubbleShouldSetFrom is true here, responderID === topLevelTargetID
  // i.e. current JS responder is still inner scroller
  var bubbleShouldSetFrom = !responderID ?
    topLevelTargetID :
    ReactInstanceHandles._getFirstCommonAncestorID(responderID, topLevelTargetID);

 ...

  if (skipOverBubbleShouldSetFrom) {
    EventPropagators.accumulateTwoPhaseDispatchesSkipTarget(shouldSetEvent);
    // shouldSetEvent._dispatchIDs === outer scroller (skipped over inner scroller?),
    // these were possibly from 'touchmove' that occurred immediately before this 'topScroll' event
  } else {
    EventPropagators.accumulateTwoPhaseDispatches(shouldSetEvent);
  }
  var wantsResponderID = executeDispatchesInOrderStopAtTrue(shouldSetEvent);

  // By the time it gets here, wantResponderID is for outer scroller

Could this be a timing issue with touch moves and scrolls? ScrollResponder.scrollResponderHandleTouchMove is consistently invoked for both inner and outer scrollers before ResponderEventPlugin.extractEvent for a scroll.

[ericf]

I've also been running into this issue. The setup I have is an outer horizontal/paging <ScrollView> with several inner vertical <ListView>s. When the <ListView>s are nested in the outer <ScrollView> I'm seeing the following warning logged when dragging the inner one:

Warning: ScrollView doesn't take rejection well - scrolls anyway

The adverse affects I'm seeing on the expected scrolling behavior of the inner <ScrollView>s is they're not respecting tapping the status bar to scroll to top, and scrolling is "sticking" to my finger when trying to continuously flick the list — the same issue that @jordanna is running into.

[jordwalke]

I'll look more into this in the coming week, but I believe the correct way to correctly integrate is to do all enabling/disabling of the scroll view completely from JS (it should start out disabled and then become enabled when JS determines it should become the JS responder). This is actually incredibly difficult because UIKit's scroll view doesn't like to work this way and it might involve some trickery.

[milanvanschaik]

Any updates on this one?

[jordwalke]

@nicklockwood: Do you know of a way to have UIScrollViews be disabled by default and then reenabled?

[nicklockwood]

You could set the scrollEnabled property to NO, or in the viewDidScrollDelegate you could reset the contentOffset to th previous value.

[jordwalke]

I tried both of those options. In the former, you cannot reenable it after touches have began, which is what would allow this issue to be fixed (and all future scroll view conflicts). I also tried the later suggestion, but I believe the momentum has issues in that case.

[nick]

Running into this issue too - I don't suppose there's been any progress here?

[jordwalke]

@vjeux, this is the kind of troubles we're having with native scroll views. The responder system solves it and I don't know how to solve it while using the UIScrollViews.

[nicholasstephan]

Any movement on this one? I have a similar example up on stack overflow (http://stackoverflow.com/questions/29756217/react-native-nested-scrollview-locking-up) that nobody has been able to answer.

[Shuangzuan]

@nicholasstephan Modify node_modules/react-native/Libraries/Components/ScrollResponder.js: Line 136 (See UPDATE):

scrollResponderHandleScrollShouldSetResponder: function(): boolean {
  return this.state.isTouching;
},

UPDATE: I find if the scroll view is currently animating and wants to become the responder, then it will reject. Line 189 in ScrollResponder.js. So I modify Line 340 and it work for me:

scrollResponderIsAnimating: function(): boolean {
  // var now = Date.now();
  // var timeSinceLastMomentumScrollEnd = now - this.state.lastMomentumScrollEndTime;
  // var isAnimating = timeSinceLastMomentumScrollEnd < IS_ANIMATING_TOUCH_START_THRESHOLD_MS ||
  //   this.state.lastMomentumScrollEndTime < this.state.lastMomentumScrollBeginTime;
  // return isAnimating;
    return false;
},

[magicismight]

Is there any progress here?

[sophiebits]

Maybe with subclassing, you can make a disableOffsetUpdates like in the gist linked here:

https://twitter.com/andy_matuschak/status/559796157241507841

Not sure if that introduces significant lag.

[sahrens]

what do you think, @ide? You seem to have the most experience with nesting and composing scroll views...

[PhilippKrone]

@ide @sahrens Any movement on this issue? I think i have exactly the same problem.

[ide]

I'm not actively looking into this. Based on what I've heard from other people and from reading this discussion, the solution could be quite hard or non-obvious without advanced knowledge of gesture systems. I have a thought regarding some of the discussion above...

Do you know of a way to have UIScrollViews be disabled by default and then reenabled?

Might be possible through the gesture recognizers by adding a custom gesture recognizer that communicates with the JS layer. I think you can tell UIScrollView's private gesture recognizers to need this custom gesture recognizer to fail -- this might let JS allow/disallow the private gesture recognizers to become active.

[sahrens]

I think @andreic has been looking at this a bit?

[sghiassy]

I'm having this issue as well. Any insights into which files to start looking into first?

[Shimaa-Hassan]

any solution?

[brentvatne]

ping @andreic 😄 we need you

[bradens]

+1 Also hitting this nasty one. Would look into it if I had more experience with gesture systems.

[amormysh]

+1

[felixakiragreen]

👍

[mkonicek]

Github issues are not working well for us - we are a very small team and and need a way to prioritize. A good way to prioritize is to let people vote on issues and Product Pains lets you do exactly that.

You can get an estimate by sorting github issues by the number of comments but it's not that reliable: https://github.com/facebook/react-native/issues?q=is%3Aissue+is%3Aopen+sort%3Acomments-desc

[toddw]

@brentvatne @ide @mkonicek fair enough, thanks for the explanations

[brentvatne]

@toddw - no problem :) thanks for weighing in on ProductPains!

[arianitu]

This has been fixed in this commit 67bf0f1 and should be coming to 0.17. Yay!

https://productpains.com/post/react-native/scrolling-ends-prematurely-in-scrollviews-embedded-in-a-parent-scrollview/

[toddw]

So stoked to see this fixed! Thanks so much!

[aksonov]

@arianitu I still see this issue in latest 0.19, why?

[Taakn]

+1 I still get it

[pppluto]

+1

[jalliance]

+1

[maraujop]

I see this happenning in 0.20 too

[neverlan]

+1 seeing this issue too

[faceyspacey]

+1 still seeing this issue. is there really no workarounds? Disabling scrolling on the parent causes lots of jerkiness.

[HaviLee]

+1,I see this issue in 0.22 too

[sandect]

+1,I see this issue in 0.22 too

[YashYash]

+1 still seeing it in .20 as well.

[dgurns]

Still seeing the same issue in 0.41!

[joaosilva05]

+1, also happening in 0.41

[bintoll]

+1, 0.46.1

[shukerullah]

+1, 0.48.3

[binchik]

+1, 0.51.0

[lishoulong]

+1, 0.50.3, And I try the following way ,but not use.

UPDATE: I find if the scroll view is currently animating and wants to become the responder, then it will reject. Line 189 in ScrollResponder.js. So I modify Line 340 and it work for me:

scrollResponderIsAnimating: function(): boolean {
// var now = Date.now();
// var timeSinceLastMomentumScrollEnd = now - this.state.lastMomentumScrollEndTime;
// var isAnimating = timeSinceLastMomentumScrollEnd < IS_ANIMATING_TOUCH_START_THRESHOLD_MS ||
// this.state.lastMomentumScrollEndTime < this.state.lastMomentumScrollBeginTime;
// return isAnimating;
return false;
},

[koloff]

+1 0.53.0

[lumiasaki]

+1 0.52.0

My scenario is using a root view in a native view controller as a separated view on iOS platform, the root view contains a <ScrollView/> component as container view, the items which in scrollview are <TouchableWithoutFeedback/>. When I scroll the scrollview, before the scrollViewDidEndDecelerating: function of UIScrollView been invoked, I press some button pushing the current view controller to another one, the scrollViewDidEndDecelerating: function will never been invoked.

When I pop back to the previous view controller, I press down the <TouchableWithoutFeedback/> in <ScrollView/> will have no effect, because the scrollResponderIsAnimating function in ScrollResponder.js, will return true because of this.state.lastMomentumScrollEndTime < this.state.lastMomentumScrollBeginTime( last momentum scroll end time didn't set properly because scrollViewDidEndDecelerating: in UIScrollView not been invoked ) , the gesture system thought that scrollview was still animating, and then the scrollview will capture the response event, not pass it to <TouchableWithoutFeedback/>.

My solution is return false from scrollResponderIsAnimating directly, but I'm still looking for a better solution.