Maybe add condition

if((widget.scrollBehavior != null) != (oldWidget.scrollBehavior != null)) {
  return true;
}

I think in such a case a call to _updatePosition is made either way, so it's handled.

I am a bit confused, if oldWidget.scrollBehavior == null but widget.scrollBehavior != null, which code path will call _updatePosition?

Hey @chunhtai in this case _updatePosition is called from didChangeDependencies.

Which dependency triggers didChangeDependencies? The scrollBehavior is a pass-in parameter and not a dependency. If you merely changing the pass-in parameter, it won't trigger didChangeDependencies.

@chinmoy12c can you take a look at this? Thanks!

Hey @chunhtai @Piinks sorry for the late reply, I've been away for a while.

@chunhtai you are right, the code does not trigger didChangeDependencies, my bad. The actual code that triggers the update is this:

ScrollPhysics? newPhysics = widget.physics ?? widget.scrollBehavior?.getScrollPhysics(context);
ScrollPhysics? oldPhysics = oldWidget.physics ?? oldWidget.scrollBehavior?.getScrollPhysics(context);

In this case either the newPhysics or the oldPhysics is null, hence

 if (newPhysics?.runtimeType != oldPhysics?.runtimeType) {
        return true;
 }

returns true.

it won't hit this case if both widget.physics and oldWidget.physics are not null even if
oldWidget.scrollBehavior == null and widget.scrollBehavior != null

If it fails to call updatePosition in this case, the _configuration will not be update with the newest widget.scrollBehavior.

I've removed the approvals while we sort this out. @chinmoy12c maybe we can add a test case for the case @chunhtai mentioned above here to better figure out this fix? :)

Hey @chunhtai thanks for pointing that out, I've added another test case to check for that behavior.
@Piinks its ready for another review :).