Panning down only on grabber when in full position if tracking scroll view

[hmoreau94]

Short description

Once we started tracking a table view inside the floating panel we obtain a strange behaviour. Indeed the content view contains a vertical stack with a 100px height view (lets call it header) and below a table view.

When the panel is in .full position and table view has a contentOffset > 0.0, then the only way to pull down the panel is to scroll down the table view back to top or to use the very small grabber.

While when the panel is in .middle or .tip position then the header view detects panGesture and makes panel position changes much easier (whatever the tracked table view content offset is). --> that's the behaviour I would always expect.

Environment

Library version 1.7.0

Installation method

• [x] CocoaPods
• [ ] Carthage
• [ ] Git submodules

iOS version(s) 13.3

Xcode version 11.3

[scenee]

If a panel is pulled down whatever the tracked table view content offset is, the table view can't be scroll anymore in full position.

Do you have any good idea of the conditions when a panel determines whether it allows to move itself or scroll the tracked scroll view?

[hmoreau94]

Hey, thanks for that quick answer, unfortunately the problem happens when the panel is up, then if the tracked table view has a non zero content offset, the only way to change the position of the tray is to touch the (very small) grabber. When the table view is not scrolled at all then both the header and the grabber can be used to change the position.

[lucio1392]

I believe this issue might related to this one https://github.com/SCENEE/FloatingPanel/issues/293.

[scenee]

@hmoreau94 Hi there, this issue also can be fixed in v1.7.2. So I would like to close this. If you still reproduce this issue, please feel free to reopen this.

[hmoreau94]

Hi @SCENEE,

I've just tried this new version and it still doesn't solve the problem :(. Here find attached a video of example. If the table view in the tray has content-offset = 0 then the grabber area is the whole superview. But otherwise it is limited to the grabber.

This is particularly strange for users, we would really need your help to figure it out.

All the best,

TrayExplanation.mov.zip

[scenee]

Hi, @hmoreau94. Thank you for your comment. I will watch the video and investigate that.

[AmitDevBol]

Hi @SCENEE, This same issue is occurring for me too, in my case write fpc.track(vc.tableView) only prevent the scrolling of content in table view but doesn't collapse or expand the panel. If you want I can also share a video.

[scenee]

I'm really sorry that I missed this issue... For now I'm not able to reproduce this issue on v2.1.0. I might be wrong. I'm so glad for you to give me more information about this issue.

[AmitDevBol]

@SCENEE I did some debugging and found some points that's different from the sample app, in this repo,

First when we scroll by holding the handleView then only activates the FloatingPanelPanGestureRecognizer same, some how the contentVC is not letting the panGesture of pc to work, Where as in demo project after the scroll end to top is called, lockScrollView() and then the control goes to handle function's FloatingPanelPanGestureRecognizer case in switch which starts the transition but, the control is not going to the FloatingPanelPanGestureRecognizer in my project.

I also debugged the view hierarchy but no view is blocking the surfaceView as far as I understand the panGesture is attached to surface view on which our contentVC is added as child.

I have attached the screenshot too.

I did tried this with an new project but it's working fine in that project, I am not able to figure out what I did wrong here, as I am heavily relying on your library for various ui in my project, I really need your help understanding how your implementation is working and to figure out what I did wrong,

If you could spare some time, I can be available to join you on shreenshare and show you my code, (Got permissions to do so 😅)

[scenee]

I forgot to change this issue status. I closed this because amit's issue wan't caused by this lib and the original issue can be fixed since 2.0. If it still happens on 2.x, please reopen this.