Fix scrollview content staying non-interactive after slowly swiping down

[sgade]

This change is what fixed a certain bug for our app: Whenever we had the FloatingPanel at full height and dragged it down, the content (which was a scroll view) locked at a negativ offset. It was most obvious when the whitespace was large, hence the offset was something around -100.0. At the same time, the contents (like buttons) were non-interactive.

Now, this behavior only surfaced recently when we needed to update our SwiftUI wrapper code. Previously, we used the code from the Map-SwiftUI example. However, once we added a TextField, the content's were not updated based on the text variable. The solution was to update the content's UIHostingController's rootView. Happy to hear if there are more efficient changes that can be done to the example code.

Please take a look at the changes of this PR and evaluate if this is actually what is supposed to happen and doesn't brake in other cases. We couldn't find any so far.

[scenee]

Thanks for your PR. I have not yet encountered that case so this is very helpful. As you mention, I do not think this change will have any side effects on other cases. I’m going to merge this patch later.

By the way, I don't get the relevance of this scroll offset issue and the text field problem you mentioned in the below.

Now, this behavior only surfaced recently when we needed to update our SwiftUI wrapper code. Previously, we used the code from the Map-SwiftUI example. However, once we added a TextField, the content's were not updated based on the text variable.

Are they different issues?

[sgade]

I cannot confidently tell you whether these are related issues. One of the reasons I framed this as a "suggestion" was to get your input on whether (a) this was a misuse on our end, (b) the fix was at the wrong location or (c) it was fine as-is.

To summarize, we adopted the code from your Maps-SwiftUI example. It's pretty much what we are doing in our app, so it was a good fit contextually. When adding a TextField, we noticed that the view was not updating correctly, i.e. updates to the existing views were possible (like changing the items in a List) but when we had an if-condition that switched between that content and the search results, it did not regard the @State. The latter should only appear when the text field is focused, the user has entered some text, etc. The problem was that no matter what I tried, we couldn't get this to work, so our solution was to update the UIHostingController's rootView whenever the updateUIViewController method was called (here).

[scenee]

Thank you so much for providing further information. I don't know what causes the TextField issue as well. But If you could file an issue and give me a sample code base on Maps-SwiftUI example in it, I would investigate this issue further more. Because I can't reproduce your issue like the below...

ResultListCell

```swift struct ResultListCell: View { let color: Color let symbolName: String let title: String let description: String @State var inputText: String = "" // Added here var body: some View { HStack { Image(systemName: symbolName) .foregroundColor(.white) .font(.headline) .padding(8) .background(Circle().fill(color)) VStack(alignment: .leading, spacing: 8) { Text(title) .font(.system(size: 20, weight: .bold)) .frame(maxWidth: .infinity, alignment: .leading) Text(description) .font(.system(size: 13)) .foregroundColor(Color(.secondaryLabel)) TextField("Input text", text: $inputText) // Added here } } .padding() } } ```

Whatever, I'll merge this PR to fix the issue where the content (which was a scroll view) can be locked at a negative offset. Thanks!

[sgade]

@scenee I can confirm your change to ResultListCell does in fact "work". However, the problem I was facing is that the state from the search bar (the user input) did not result in view updates in the view that manages the list.

It seems that this is not happening in the example because it is wrapping a UITableViewController. I tried to recreate the issue in the Maps-SwiftUI environment but all update calls are coming through as expected. One has to propagate that to all visibleCells in the end but it works.

So for now, I think I had two issues — where this PR fixed one of. The second might have something to do with our view architecture. I will create an issue if I find that it is related to the FloatingPanel package.

Thanks to you and all the other authors for this package and the continued support! 🚀

[scenee]

@sgade

I found an issue on this change reported in #602 and #603. So I reverted the change in v2.6.6. I'm really sorry that I couldn’t find the issue on this review.

By the way, I've added an additional change in v2.6.6 to fix another issue I found on scroll offset. The change might be related to your issue, "the offset was something around -100.0.".

I was wondering if you could check if your issue has been resolved in 2.6.6 or not. I'd appreciated it.

[sgade]

@scenee Thanks for the heads-up. I have looked into the other changes and of course it was wrong to only check for the y axis. Sorry for only thinking about the one use case in this PR.

I have tested out 2.6.6 and the issue that lead me to create this PR does not seem to resurface again. 👍 We'll test this out a bit more and come back to you if needed.

Thanks again for your support!