maui
maui copied to clipboard
dotnet
ScrollView and VerticalStackLayout do not resize themselves on iOS
Description
ScrollView and VerticalStackLayout do not resize themselves on iOS as they do on Android.
On toggling a control that is initially visible to be hidden. There is a blank space left where the control used to be.
If the control is set to be hidden initially and then toggled to be visible. The VerticalStackLayout and ScrollView do not resize to take into account the size of the now visible control.
Steps to Reproduce
Clone repo https://github.com/ammar-madni/MauiResizeIssueIOS
Run on android to see intended result.
Run on iOS to see the issue on iOS.
Version with bug
6.0.408 (current)
Last version that worked well
6.0.312
Affected platforms
iOS
Affected platform versions
iOS 15.5
Did you find any workaround?
I have added a margin to the bottom of the last element in VStack. This margin gets used up when the Hidden Control is toggled to be visible.
Relevant log output
No response
I just tested on Sr3 (6.0.409) and it's almost working , it seems the VerticalSttackLayout resizes fine, but the Scrollview doesn't.
I also have this issue. My use case is I have a screen full of content with buttons at the bottom. In the middle of the screen, there is a label with LineBreakMode="WordWrap" inside of a Grid with the RowHeight set to Star. When the text of that label wraps beyond one line, the content of the scrollview increases that many pixels past the height of the scrollview. Essentially two line wraps and the bottom button is pushed off the screen. You can pull the scrollview to see the button but when you let go, it snaps back below the screen.
Basic structure (attributes removed for brevity):
<ScrollView >
<VerticalStackLayout >
<Frame>
<Grid
ColumnDefinitions="2*,3*"
RowDefinitions="*,*,*,*,*,*,*,*,*,*,*,*">
<!-- lots of content -->
<Label Grid.Column="1" Grid.Row="12" Text="{Binding LotsOfText}" LineBreakMode="WordWrap" />
</Grid>
</Frame>
<!-- lots of content -->
<Button />
<Button />
</VerticalStackLayout>
</ScrollView>
This is really frustrating because now I have to change how the information is laid out on the screen so that the users can tap the button at the bottom. I will most likely have to do a fixed height on the label/GridRow that should account for the most amount of text we should have but that leaves a ton of whitespace if there isn't any text.
I also had this issue and I could resolve it by manually calling the layout update on the scrollview. In my case I have a VerticalStackLayout using BindableLayout.ItemsSource where items are added and removed dynamically. So I think this should work similar to switching between hidden and visible items.
<ScrollView x:Name="ScrollView"><VerticalStackLayout>...</VerticalStackLayout></ScrollView>
In the code behind I added this:
private void OnItemsChanged(object sender, EventArgs e) { (ScrollView as IView).InvalidateMeasure(); }
Hope this works for you, too!
Thank you @EPS-Lac for the share. I was facing a similar issue with dynamically expanding/resizing web views within scroll views described here.
Using your example I was able to work around this issue by manually notifying any parent ScrollViews to invalidate their measures.
In the code behind I added this:
private void OnItemsChanged(object sender, EventArgs e) { (ScrollView as IView).InvalidateMeasure(); }Hope this works for you, too!
Very nice solution. I had an async data loading situation, invoking the InvalidateMeasure() via an Action from my ViewModel did the trick.
I think it works well if you bind the OnItemsChanged to the SizeChanged event of the VerticalStackLayout. Just noticed it in one case, but that's probably the same for all cases.
@EPS-Lac thank you for the workaround, it works really well!
However, in my solution, SizeChanged does not work, but if I use PropertyChanged instead, it does. I also needed to add a null check in my event handler:
<ScrollView x:Name="scrollView">
<VerticalStackLayout PropertyChanged="VerticalStackLayout_PropertyChanged">
private void VerticalStackLayout_PropertyChanged(object sender, System.ComponentModel.PropertyChangedEventArgs e)
{
(scrollView as IView)?.InvalidateMeasure();
}
This gets called quite often, but still better than an unaccesible view.
@EPS-Lac oh man, thanks a lot! I was looking for a workaround for this bug a long time!
Wonder if this is a duplicate of #9209 ?
Another repro here: https://github.com/durandt/maui-issue2-ios-stacklayout-scroll
A similar thing seems to occur for me in a BindableLayout. When I add items beyond the size of the screen the parent scrollview doesn't seem to expand. I was able to fix this using the above workaround. I added a few modifications. I have posted them below in case anyone is interested.
in xaml:
<ScrollView x:Name="MainScrollView">
<StackLayout x:Name="MainLayout">
<StackLayout BindableLayout.ItemsSource="{Binding Items}">
<!-- etc.. -->
in xaml.cs:
protected override void OnAppearing()
{
base.OnAppearing();
MainLayout.PropertyChanged += UpdateView;
}
protected override void OnDisappearing()
{
base.OnDisappearing();
MainLayout.PropertyChanged -= UpdateView;
}
void UpdateView(object sender, PropertyChangedEventArgs e)
{
(MainScrollView as IView)?.InvalidateMeasure();
}
@hartez I´m not sure the bug has gone away. When I have a ScrollView and a VerticalStackLayout inside and load content dynamically, i.e. some text (using an async function) and at the bottom of the VerticalStackLayout there is a button, the command never gets fired when the button is clicked. One can see the Button, but it´s handler doesn´t get called. When I reapply @borrmann ´s workaround, the handler gets called.
Hello lovely human, thank you for your comment on this issue. Because this issue has been closed for a period of time, please strongly consider opening a new issue linking to this issue instead to ensure better visibility of your comment. Thank you!
@FM1973 @borrmann This sounds like it might be a slightly different issue (since you can see the button).
Can you open a new issue with a repro specific to this problem? Thanks!
@hartez Ok, I opened a new issue. #14257 I still think it´s the same problem. And please no "duplicate issue ping pong"!