[Bug][Regression] StackLayout doesn't render correctly on Android Xamarin.Forms 5

[tritter]

Description

Items inside StackLayout get lost, whenever they are added after initial rendering. This issue only appears on Android and whenever the StackLayout renders outside the screen bounds.

Steps to Reproduce

1. Press Add Button
2. Scroll down to the end of the list.

Expected Behavior

Last item is visible.

Actual Behavior

Last item is not visible only the reserved space.

Basic Information

• Version with issue: 5.0.0.xx
• Last known good version: 4.8.0.1821
• Platform Target Frameworks: 30
  • Android: Tested several 28,29,30
• Android Support Library / AndroidX Version: (see attached sample code)
• NuGet Packages: Xamarin.Forms (see attached sample code)
• Affected Devices: Tested with several Android devices and emulators.

Environment

Show/Hide Visual Studio info

=== Visual Studio Community 2019 for Mac ===

Version 8.10.11 (build 8)
Installation UUID: eae99a74-64f6-486f-90f0-62e04ddc7b39
	GTK+ 2.24.23 (Raleigh theme)
	Xamarin.Mac 6.18.0.23 (d16-6 / 088c73638)

	Package version: 612000140

=== Mono Framework MDK ===

Runtime:
	Mono 6.12.0.140 (2020-02/51d876a041e) (64-bit)
	Package version: 612000140

=== Roslyn (Language Service) ===

3.10.0-4.21269.26+029847714208ebe49668667c60ea5b0a294e0fcb

=== NuGet ===

Version: 5.9.0.7134

=== .NET Core SDK ===

SDK: /usr/local/share/dotnet/sdk/6.0.100-preview.7.21379.14/Sdks
SDK Versions:
	6.0.100-preview.7.21379.14
	5.0.402
	5.0.401
	5.0.302
	5.0.301
	5.0.203
	5.0.202
	5.0.201
	5.0.102
	5.0.101
	5.0.100
	3.1.414
	3.1.413
	3.1.411
	3.1.410
	3.1.409
	3.1.408
	3.1.407
	3.1.405
	3.1.404
	3.1.403
	3.1.402
	3.1.401
	3.1.302
	3.1.301
	3.1.300
	3.1.200
	3.1.102
	3.1.101
	3.1.100
	3.0.101
	3.0.100
MSBuild SDKs: /Applications/Visual Studio.app/Contents/Resources/lib/monodevelop/bin/MSBuild/Current/bin/Sdks

=== .NET Core Runtime ===

Runtime: /usr/local/share/dotnet/dotnet
Runtime Versions:
	6.0.0-preview.7.21377.19
	5.0.11
	5.0.10
	5.0.8
	5.0.7
	5.0.6
	5.0.5
	5.0.4
	5.0.2
	5.0.1
	5.0.0
	3.1.20
	3.1.19
	3.1.17
	3.1.16
	3.1.15
	3.1.14
	3.1.13
	3.1.11
	3.1.10
	3.1.9
	3.1.8
	3.1.7
	3.1.6
	3.1.5
	3.1.4
	3.1.2
	3.1.1
	3.1.0
	3.0.1
	3.0.0
	2.1.23
	2.1.22
	2.1.21
	2.1.20
	2.1.19
	2.1.18
	2.1.17
	2.1.16
	2.1.15
	2.1.14
	2.1.13

=== .NET Core 3.1 SDK ===

SDK: 3.1.414

=== Xamarin.Profiler ===

Version: 1.6.12.29
Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler

=== Updater ===

Version: 11

=== Xamarin.Android ===

Version: 11.3.0.4 (Visual Studio Community)
Commit: xamarin-android/d16-10/ae14caf
Android SDK: /Users/thom/Library/Android/sdk
	Supported Android versions:
		6.0 (API level 23)
		7.1 (API level 25)
		8.1 (API level 27)

SDK Tools Version: 26.1.1
SDK Platform Tools Version: 31.0.2
SDK Build Tools Version: 30.0.3

Build Information: 
Mono: b4a3858
Java.Interop: xamarin/java.interop/d16-10@f39db25
ProGuard: Guardsquare/proguard/v7.0.1@912d149
SQLite: xamarin/sqlite/3.35.4@85460d3
Xamarin.Android Tools: xamarin/xamarin-android-tools/d16-10@c5732a0

=== Microsoft OpenJDK for Mobile ===

Java SDK: /Users/thom/Library/Developer/Xamarin/jdk/microsoft_dist_openjdk_1.8.0.25
1.8.0-25
Android Designer EPL code available here:
https://github.com/xamarin/AndroidDesigner.EPL

=== Android SDK Manager ===

Version: 16.10.0.13
Hash: 1b81df5
Branch: remotes/origin/d16-10
Build date: 2021-09-21 02:30:50 UTC

=== Android Device Manager ===

Version: 16.10.0.15
Hash: 89dcc0b
Branch: remotes/origin/d16-10
Build date: 2021-09-21 02:31:08 UTC

=== Apple Developer Tools ===

Xcode 13.0 (19234)
Build 13A233

=== Xamarin.Mac ===

Version: 7.14.0.27 (Visual Studio Community)
Hash: 2566861a9
Branch: d16-10
Build date: 2021-07-27 02:34:12-0400

=== Xamarin.iOS ===

Version: 15.0.0.6 (Visual Studio Community)
Hash: 2771277e0
Branch: xcode13-ios
Build date: 2021-09-23 10:36:08-0400

=== Xamarin Designer ===

Version: 16.10.0.119
Hash: 36a2d986f
Branch: remotes/origin/d16-10
Build date: 2021-06-02 19:41:34 UTC

=== Build Information ===

Release ID: 810110008
Git revision: 5467245e1f99a0c8ccdd2acea02d16c3fb65c220
Build date: 2021-10-07 10:49:46-04
Build branch: release-8.10

=== Operating System ===

Mac OS X 10.16.0
Darwin 20.6.0 Darwin Kernel Version 20.6.0
    Mon Aug 30 06:12:21 PDT 2021
    root:xnu-7195.141.6~3/RELEASE_X86_64 x86_64

Build Logs

Screenshots

Reproduction Link

https://github.com/tritter/forms-stacklayout-bug

Workaround

No, unfortunately not, this project is just a demonstration. In our app we use multiple StackLayouts to accomplish an interactive form, which is not replaceable by a 'simple' ListView which does not have the problem. At the moment we're stuck at Xamarin Forms 4.8!

[tritter]

This issue seems to be related: #14398

[Dreamescaper]

Probably same as #14569.

[holecekp]

I have the same problem. When I change IsVisible for controls in StackLayout (in combination with ScrollView) in run-time, or when I use lazily loaded controls, the height of the StackLayout is not always updated and the controls can end up outside the visible area of the screen.

[radioactiveman]

Hi @jfversluis, @davidortinau,
Is there any update on this issue(s)? Is a fix scheduled for a coming service release?
Please prioritize regressions like this. They are annoying, especially if you cannot downgrade to an older Xamarin.Forms version because of other bug fixes or better iOS 15 support for example. Thanks.

[holecekp]

Yes, please. This is very annoying problem.

[jfversluis]

Unfortunately not :( of course feel free to poke around the Xamarin.Forms source to see if you can find more details as to why this might be happening while we get to this one.

[AswinPG]

I am facing this issue when using scrollview in both ios and Android. This is a critical bug and happens randomly. I can't release any of my apps because we don't know how it'll behave.

[holecekp]

This is really a horrible bug. I have spent almost an hour looking for a workaround. I have tried calling ForceLayout on various controls, which helped me a few times in the past with similar Xamarin.Forms bugs, but unfortunately it does not help for this one.

The only thing that helps a little is to add a transparent control to the end of the StackLayout. If the height of this transparent control is greater than a certain threshold then some, or all of the controls, which were invisible because of the bug, are shown.

Something like this:

                <Grid IsVisible="{OnPlatform Android=true, Default=false}">
                    <BoxView BackgroundColor="Transparent" HeightRequest="300" IsVisible="{Binding AllowErrorReporting, Converter={StaticResource invertedBoolConverter}}" />
                </Grid>

The goal is to keep the height of the ScrollView content more or less the same on Android. This creates a blank space on some scenarios so the app will look ugly. But unfortunately, ugly but functional app can be sometimes still considered as a victory on Xamarin.Forms :-(. I really wish that the upcoming MAUI would not inherit all these bugs.

[holecekp]

Workaround: I have finally found something that works well for this issue. This workaround has been proposed originally for another ScrollView issue (#13597) but I have found out that it helps also for this issue.

The workaround is to enclose the ScrollView into a ContentView.

So instead of:

<ScrollView>
  <StackLayout>...</StackLayout>
</ScrollView>

it should be:

<ContentView>
   <ScrollView>
     <StackLayout>...</StackLayout>
   </ScrollView>
</ContentView>

It seems that ScrollView is buggy if it is the root element of the page. Adding a ContentView into the hierarchy prevents this.

[jfversluis]

Thanks for letting us know @holecekp hopefully this will also be some hint in order to fix this!

[jfversluis]

Hey everyone a PR (#15066) has been opened that looks like it might address this issue. Would someone (or of course multiple people preferably 😄) be able to grab the NuGet as described here and let us know if this fixes this issue? That will greatly speed up the review process.

Besides verifying if this particular issue is fixed also be sure to check other scenarios in the same area to make sure that this fix doesn't accidentally has side-effects 🙂

Thanks!

[holecekp]

@jfversluis Hello. I have tested the PR and I confirm it fixed the issue for me. It is no longer necessary to use the ContentView workaround. I have tested on Android and UWP.

[jfversluis]

Thanks so much @holecekp !

[tritter]

@jfversluis For me and the sample App attached above its also resolved. Thanks a lot!

[GreatBarrier86]

@jfversluis, well done. Looks good here too.

[jfversluis]

This should be fixed by #15076 and part of SR10