[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;
},