When the content inside a scrollview changes size the Scrollview does not resize itself. The effect is that when content gets smaller a gap is left where the content used to be, when content gets bigger it cannot be seen. This only happens when the ScrollView is inside a Page that is the Detail of a MasterDetailPage. If the Detail is a NavigationPage then the Scrollview works correctly.
In the reproduction solution mdp.xaml.cs in the PCL is the page that set the Detail, on initial load there will be a NavigationPage. To reproduce in the Reproduction
Note, I can't remember whether the uploaded reproduction is referencing the Xamarin.Forms version that works or the one that doesn't work. Please ensure that the Xamarin.Forms references are set to 2.4.0.91020 or later.
Layout is adjusted/redrawn so controls occupy the ScrollView without leaving empty space.
Empty space is left where the (now) smaller control used to occupy. The Draw method in the ScrollViewRenderer never gets called, although the ContentSizeProperty does trigger a PropertyChanged event.
Hi, I think that this bug is related to 60453 and 60399 on Bugzilla. Its confirmed on 2.5.0 sr2.
I'm having the same problem, some components missing, different behavior in different Android APIs, and so on. I think that the problem is related to the HorizontalOptions of controls inside a Page.Content when this Content is a ScrollView. As commented on 60453, I fixed my solution with this workaround, as described below:
"
...
Upon further analysis, I think that the problem has something involved with the HorizontalOptions of the ScrollView inside a MasterDetailPage. In my tests, I have a MasterDetailPage and my Detail page has a ScrollView setted as the Content of the page, with some StackLayouts inside, besides another components (Labels, Images, etc).
If we redefine the HorizontalOptions from the Page.Content (to any value) and the HorizontalOptions from the ScrollView (to anything diferent from Fill / FillAndExpand, like CenterAndExpand), the content will appear correctly in any API version that I have tested.
But there is a implication with this workaround, I think that when we add some components inside the Content of the ScrollView or inside the Content of any of its children (like StackLayouts), the widths of them all may be recalculated and the bug comes back (hiding some controls), so its important that you define these HorizontalOptions AFTER you add any components that you need.
In my case, I have a ScrollView and in my constructor I set it as the Content of the Detail page. After that, terminating another method where I add some more controls inside the ScrollView, I have to redefine both the HorizontalOptions:
myScrollView.HorizontalOptions = LayoutOptions.CenterAndExpand;
this.Content.HorizontalOptions = LayoutOptions.FillAndExpand;
Doing this, all controls visibility works as expected in any API version.
Hope that it can help!"
One more thing, when we do a page rotation on any device, the components reappear.
* Note that the behavior of this bug on Android 4.3 or less is worse than 4.4 and up;
@shipjacker
It does look a very similar issue and it's good the workaround works for you, unfortunately for me it didn't work 😭
I only observed this on my app on android < 4.4 - but it is still a blocker and got me stuck on 2.3.4.
These are most likely the same issue:
https://bugzilla.xamarin.com/show_bug.cgi?id=60155
https://bugzilla.xamarin.com/show_bug.cgi?id=60436
Any news?
+1
+1
We’re also facing this issue in our project. Would be great if this could be fixed within the next few weeks.
Everyone should mention the Android platform where this issue can be observed. If possible, maybe also test on different Android versions. Anything which can help debugging the issue.
I can confirm the issue on Android 4.1 and 4.2. We've been stuck with Forms 2.3.x for quite a while now. Is there a planned release date for the fix?
I ended up using FlowListView, and put all my view in one cell. Works fine, but not so convinient. Now I going to use something like this again.
We've been forced to drop android <4.4 support due to this, thankfully most users already migrated to newer versions. It is a bit disappointing that this issue is still not resolved as this is something that makes affected apps completely unusable on these devices.
It's still an issue for us, regardless of Android version used (even on Oreo).
This is a big problem for us as it is cutting off the controls/views at the bottom of our pages. We utilize Master/Detail with absolute layouts wrapping scroll views.
Tried various android versions on different devices and emulators with no change. Appeared when we updated to 2.5.1.444934 from 2.4
There is a "workaround" (more like an awful hack):
Open the keyboard for more than 100ms und close it again, this forces the GUI to refresh and "fixes" most problems on most Android versions.
Given how this is severe and breaks existing behaviour I'm surprised
a) It's not scheduled for fix on v2 maintenance
b) It's not actually scheduled for vNext but for vNext+1
How is this going to be broken for @jassmith?
In our case helped setting android:hardwareAccelerated="true"
I was having performance issues with no apparent reason, so I tried to set the android:hardwareAccelerated on, but didn't find a way, but it is activated by default if you set your TargetPlatform to IceCreamSandwich or above, so I set it to Oreo and now it runs smooth!
Thanks a lot @dawidkraczkowski
We just updated to the latest release and the problem still exists for us.
The button at the bottom of the screen should float at the bottom of the screen but is always rendered beneath the fold.
Updating to Xamarin.Forms 3.1.0.697729 did not fix the issue. The bug seems to still be present.
is still present :(
This indeed does not seem fully fixed
update - The behaviour in the sample below works as expected when tested with Xamarin.Forms 3.5.0.129452 with support v28.0.0.1.
I have a similar problem. In my case, the updated bounds are not propagating to child elements as expected when the device rotates.
I found that toggling a frame's visibility affects subsequent layout propagation of invisible frames.
Steps to reproduce
1) Create an absolute layout.
2) Add a frame as a child element with a second frame as its child.
3) Toggle the first frame's visibility off and on.
4) Set the first frame's visibility to off.
5) Resize layout.
6) Set the first frame's visibility to on.
Expected behaviour
The second frame's layout is updated to match the first.
Actual behaviour
The second frame's layout isn't updated.
tested with
Android 24 and 28
Xamarin.Forms 3.2.0.871581 and 3.3.0.775299-nightly
Xamarin.Support 27.0.2.1
Fixed this by Calling InitializeComponent() method on "Appearing override Method".
Any fixes for this issue?
This issue doesn't seem to have had any activity in a long time. We're working on prioritizing issues and resolving them as quickly as we can. To help us get through the list, we would appreciate an update from you to let us know if this is still affecting you on the latest version of Xamarin.Forms, since it's possible that we may have resolved this as part of another related or duplicate issue. If we don't see any new activity on this issue in the next 30 days, we'll evaluate whether this issue should be closed. Thank you!