[iOS] NullReferenceException from FlexLayout.InitItemProperties #21711
Labels
fixed-in-8.0.21
fixed-in-9.0.0-preview.4.10690
i/regression
This issue described a confirmed regression on a currently supported version
platform/iOS 🍎
s/triaged
Issue has been reviewed
s/verified
Verified / Reproducible Issue ready for Engineering Triage
t/bug
Something isn't working
Milestone
Comments
Zhanglirong-Winnie
added
s/verified
|
Verified this issue with Visual Studio 17.10.0 Preview 2(8.0.10 & 8.0.14 & 8.0.40-nightly.10455+sha.998f884315-azdo.9383879). Can repro on iOS platform with sample project. |
|
I was able to narrow this down to a much simpler set of code: FlexLayout flex = null!;
Content = new VerticalStackLayout
{
new Button
{
Text = "GO!",
Command = new Command(() =>
{
flex.Clear();
var label = new Label
{
Text = "Hello",
Background = Brush.Yellow,
TextType = TextType.Html
};
flex.Add(label);
})
},
(flex = new FlexLayout { }),
};If you click the button the first time, then it works. However, pressing it again causes it to throw the same error. Seems |
|
The reason the crash is appearing is because there is a "race" condition. It seems that the first time I add a label, all is well. However, the second time, setting the label text somehow triggers a layout of the UI which will try and layout the items... while they are being added. The last 2 lines are the setting of the text during the construction/addition of the label view. The first line is the start of a layout. In between, something causes a layout. |
|
Hi @mattleibow, I was thinking the same when debugging this. But what is also interesting to me is that an add to the itemssource is generating an add in the flexlayout, than a clear/reset and than an add again.. I would have expected an single add would do it. But thanks looking into this and breaking it down |
mattleibow
added a commit
that referenced
this issue
Apr 9, 2024
Fixes #21711 In some cases, adding an item before may trigger an update before the add operation is complete. For example, adding a label with HTML text may cause the layout to run while the label is being constructed. To prevent that layout pass from crashing because the flex item is not yet set, we make sure to first set the flex item, and then add it to the layout. Then, when the layout pass runs, the item is ready to be used. This error might not typically appear in normal XAML layouts because the items are first set, and then the entire page is inflated. However, if the layout is part of a CollectionView or items are added dynamically after the UI is loaded, this layout during add may occur.
|
@Larhei do you have a sample of this:
I think my PR may fix that as it appeared adding items dynamically to the FlexLayout after it was visible would trigger issues. So, if you have a sample then I can test. |
|
Hi @mattleibow, not right now. but in a few hours I try to build on. |
|
Hi @mattleibow, I added a Second Project to the Repository to showcase the issue. Long story short.
Callstack |
|
OK, I will try test. I am seeing this: Which is basically the same issue. Instantiating the |
|
I think this PR also fixed that issue. I tried the nugets from this PR and it seems to no longer crash. |
PureWeen
pushed a commit
that referenced
this issue
Apr 10, 2024
* Init the flex item before adding it to the layout Fixes #21711 In some cases, adding an item before may trigger an update before the add operation is complete. For example, adding a label with HTML text may cause the layout to run while the label is being constructed. To prevent that layout pass from crashing because the flex item is not yet set, we make sure to first set the flex item, and then add it to the layout. Then, when the layout pass runs, the item is ready to be used. This error might not typically appear in normal XAML layouts because the items are first set, and then the entire page is inflated. However, if the layout is part of a CollectionView or items are added dynamically after the UI is loaded, this layout during add may occur. * This too * UI tests * AutomationId is important :)
|
Thank you for letting us know @Larhei |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Description
After upgrading to the new maui version we are seeing a crash on iOS in on of our views.
The Callstack is
(see relevant log output for complete stack trace)
In our ViewModel we are adding items to an Observable Collection in a foreach loop with some delay.
This ObservableCollection is bound to a CollectionView.
Before Maui Version 8.0.14 this exception only happened when the Cell was not initial in the viewport and when scrolling it into view. So we changed our layout logic to have this cells in the viewport to not facing the issue. But now also views in the initial viewport are getting this null pointer. From my debugging it looks to me that even when setting Binding to OneTime the BindableLayout.ItemsSource is behaving interesting.
When Subclassing Flexlayout the OnAddItem for each item in the Modes Collection is called. This is expected.
Then there comes Layout. This is expected also.
But than there comes a OnClear call for unknown reason... than OnAddItem for first item in Modes Collection... and than Layout again. And this is not expected. I did not change the Mode Collection in the ItemsSource. My ItemsSource contains more than one item. So why it only want to layout that single item... unknown.
The NullPointer is caused by
GetFlexItem(BindableObject bindable)returning nullThis can only happen if AddFlexItem is called when _root is null. And this is the case I guess because the call to OnClear sets _root to null.
But this just my2cents.
Steps to Reproduce
Link to public reproduction project repository
https://github.com/Larhei/Maui-Issues/tree/main/FlexLayout
Version with bug
8.0.14 SR3.1
Is this a regression from previous behavior?
Yes, this used to work in .NET MAUI
Last version that worked well
8.0.7 SR2
Affected platforms
iOS
Affected platform versions
No response
Did you find any workaround?
Remove TextType="Html" from the Label. But I really need HTML text here.
Relevant log output
The text was updated successfully, but these errors were encountered: