Weird behavior when scrolling fast.

[jrr363]

Description

The floating panel view seems not to be pinned to the bottom When selecting a cell and scrolling fast the bottom of the view controller will start to move vertically along with the scrollview.

Expected behavior

Actual behavior

https://user-images.githubusercontent.com/5199806/212200717-bed3e818-734c-4052-90e4-876f817e6e39.mp4

Steps to reproduce

Scrolling quickly on a UITableVIew

Code example that reproduces the issue func fpcInstance(viewController: UIViewController, scrollView: UIScrollView?, initalPosition: FloatingPanelState) -> FloatingPanelController { let fpc = FloatingPanelController() fpc.contentMode = .static //.fitToBounds ///// static == The option to fix the content to keep the height of the top most position. //update content size fpc.delegate = fpcDelegate fpc.set(contentViewController: viewController) if let realScrollView = scrollView { fpc.track(scrollView: realScrollView) } fpc.surfaceView.backgroundColor = .clear fpc.isRemovalInteractionEnabled = false fpc.addPanel(toParent: self, animated: false) fpc.move(to: initalPosition, animated: false) fpc.setAppearanceForPhone() return fpc } How do you display panel(s)? Add as child view controllers and presented modally

How many panels do you displays? 2+

Environment

Library version

Installation method import the actual swift files

iOS version(s) iOS 15, 16

Xcode version 14.1, 14.2

[scenee]

This is because the size of the content view(= the visual effect view) depends on the most expanded(top most) size in static content mode . To fix this cut-off, you can add the visual effect view into fpc.surfaceView.containerView, which extends to the size of the content plus fpc.view size. As a result, the cut-off will effectively no longer occur.

[mandaryn4k]

This is because the size of the content view(= the visual effect view) depends on the most expanded(top most) size in static content mode . To fix this cut-off, you can add the visual effect view into fpc.surfaceView.containerView, which extends to the size of the content plus fpc.view size. As a result, the cut-off will effectively no longer occur.

Can you provide more details?) I noticed that it reproduces when absoluteInset = 0.0 for "full" anchor, if it is 1, everything is ok. var anchors: [FloatingPanelState: FloatingPanelLayoutAnchoring] { return [ .full: FloatingPanelLayoutAnchor(absoluteInset: 0.0, edge: .top, referenceGuide: .superview), .half: FloatingPanelLayoutAnchor(fractionalInset: 0.5, edge: .bottom, referenceGuide: .safeArea), .tip: FloatingPanelLayoutAnchor(absoluteInset: 80.0, edge: .bottom, referenceGuide: .safeArea), ] }

[scenee]

hi, @mandaryn4k

First, just try the following code, you can see the background color change of the fpc.surfaceView.containerView and there is no cut-off of the background.

        let appearance = SurfaceAppearance()
        appearance.backgroundColor = .red
        surfaceView.appearance = appearance

fpc.surfaceView.containerView is expanded double up to the fpc.view.bounds.height if fpc.contentMode is .static. Besides, you can add any subview.

The following code add a visual effect view, for example.

        let effect = UIBlurEffect(style: .prominent)
        let effectView = UIVisualEffectView(effect: effect)
        fpc.surfaceView.containerView.addSubview(effectView)
        effectView.frame = fpc.surfaceView.containerView.bounds
        effectView.autoresizingMask = [.flexibleWidth, .flexibleHeight]

I noticed that it reproduces when absoluteInset = 0.0 for "full" anchor, if it is 1, everything is ok.

I'm sorry I tied to reproduce your case with the Maps example code but I couldn't. The behavior didn't change by the absoluteOffset value.