You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Once again we have found a problem, that seems happen because of the changes to the way to find the drivingScrollView. Also once again I have not been able to create a simple example of the crash.
The problem
The problem seems to be caused by changing the content of the Overlay, so that the drivingScrollView is changed. By that I mean that there is a completely new drivingScrollView. This I was able to determine, because we have found that a possible workaround is to only have a single ScrollView that is always the drivingScrollView. Unfortunately that would render the changes to find the correct scroll view nearly useless.
The following stacktrace/crashreport is reported by XCode:
With all the problems that the new solution seems to incur, I'm starting to believe that it is to fragile. Maybe instead the solution that I had proposed would be better (determining it through the accessibilityIdentifier), even if we need to use UIViewControlelrRepresentable to make it work. The restriction to not put an Overlay into a NavigationView if the title should be hidden seems less of a problem to me than this.
The text was updated successfully, but these errors were encountered:
Well if you can check in OverlayContainer, if the drivingScrollView still exists, then I would classify it as a OverlayContainer Problem.
And yes I would love to give you an example, but I still have not managed to make an example, only our production code has this problem and as you can guess, I'm not allowed to upload that.
Once again we have found a problem, that seems happen because of the changes to the way to find the drivingScrollView. Also once again I have not been able to create a simple example of the crash.
The problem
The problem seems to be caused by changing the content of the Overlay, so that the drivingScrollView is changed. By that I mean that there is a completely new drivingScrollView. This I was able to determine, because we have found that a possible workaround is to only have a single ScrollView that is always the drivingScrollView. Unfortunately that would render the changes to find the correct scroll view nearly useless.
The following stacktrace/crashreport is reported by XCode:
With all the problems that the new solution seems to incur, I'm starting to believe that it is to fragile. Maybe instead the solution that I had proposed would be better (determining it through the accessibilityIdentifier), even if we need to use UIViewControlelrRepresentable to make it work. The restriction to not put an Overlay into a NavigationView if the title should be hidden seems less of a problem to me than this.
The text was updated successfully, but these errors were encountered: