Make sure that we have valid values for setting the ContentSize of the ScrollView on iOS

[hartez]

Description of Change

Updated version of #14143. Simplified things a little, added comments for clarity.

fixes #15079
fixes (but not really) #14257

[github-actions]

Thank you for your pull request. We are auto-formatting your source code to follow our code guidelines.

[rmarinho]

/backport to release/8.0.1xx-preview3

[github-actions]

Started backporting to release/8.0.1xx-preview3: https://github.com/dotnet/maui/actions/runs/4545732552

[JohnHDev]

@hartez any way of tracking which build this fix is going/gone in to? We use gittag's in Jira for this, any equivalent here?

[hartez]

We have a bot that labels PRs with their initial release versions; I'm not sure why it hasn't labeled this. But it's available in the latest .NET 8 preview; it has not yet been backported to 7. The backport/suggested label means it will be in our next backport review; assuming it meets the criteria we'll backport it and it will show up in the following service release.

[JohnHDev]

@hartez thank you for the update, that's helpful.
I have to ask though, why aren't bug fixes going directly into .NET 7 as that is the current production version and then merged forward into .NET 8?

[hartez]

Because all code changes to the stable version run a non-zero risk of regression, and not all bugs are severe enough to warrant that risk. And some (very few) bug fixes require breaking changes, so they can't be done in 7 at all. So we do the bug fixes in 8, where we still have time to surface problems prior to stable release. For bugs where the severity is high enough (weighed against the complexity of the fix), we create a backport PR and add it to a service release for 7 (and possibly 6, if it meets the bar we've set).

[softlion]

There are so few people using Maui net7 in production, why not include breaking changes.

[DDHSchmidt]

There are so few people using Maui net7 in production, why not include breaking changes.

Following that logic will lead to a self-fulfilling prophecy:
"Why is no one using .Net 7?"
"There are too many bugs in it"
"So why aren't they fixing them?"
"Everyone fled to .Net 8, so why bother fixing 7 at all?"

For us, the last 2 Service Releases after 7.0.59 contained so many breaking regression bugs that we had to sit them out, which means no updates for almost 4 months.
While e.g. the touted memory leak fixes would be very much welcomed, they're useless if all of our grids break, again and again :(

We're eagerly awaiting every new .Net 7 SR, hoping that we can finally upgrade but at this point it really feels like Microsoft wants everyone to be a .Net 8 beta tester anyway...

[JohnHDev]

Because all code changes to the stable version run a non-zero risk of regression, and not all bugs are severe enough to warrant that risk. And some (very few) bug fixes require breaking changes, so they can't be done in 7 at all. So we do the bug fixes in 8, where we still have time to surface problems prior to stable release. For bugs where the severity is high enough (weighed against the complexity of the fix), we create a backport PR and add it to a service release for 7 (and possibly 6, if it meets the bar we've set).

@hartez thanks, do you know if this will be merged back into .NET 7? If not, when is .NET 8 due for release?
We have a hard deadline of May 1st, 2024 to move off Xamarin. .NET 7 is current production and we cannot move to .NET 8 until it is released and we can't start the migration to .NET Maui until our features can be migrated.

[softlion]

Following that logic will lead to a self-fulfilling prophecy:
...
it really feels like Microsoft wants everyone to be a .Net 8 beta tester anyway...

I'm not sure if you are with or against me at that point.

I do have the same requirements.

Both a production app using net7 that is waiting for an update that I can't release because of "suddenly" poor performances everywhere (not only in collection views).I don't care about breaking changes as people using net7 are on the edge anyway, and can bear with breaking changes.

And a large xamarin app that I would like to start migrating at least 6 months before the end of xamarin support.

[JohnHDev]

@hartez I haven't seen a reply to my previous question but I see the .NET 8 release date is November, why are production bugs not being fixed in .NET 7 first? Do we really have to wait 5 months for fixes that MS doesn't deem as High?
You marked by ticket as fixed and closed, but I have no idea if the fix will be in .NET 7 or not. All I know is that it might be fixed (I haven't tested it) in future version which may or may not have even more regressions.

A November release date only gives us a 6 month window to migrate our monolithic Xamarin Forms apps, when we don't know if it will even work. Please please please, you (MS) have got to give us better support than this.

@davidortinau are you aware of the process described above?

[hartez]

do you know if this will be merged back into .NET 7? If not, when is .NET 8 due for release?

It's been marked for consideration as a backport (that's what the "backport suggested" label is for); we'll be evaluating it soon and determining whether we can backport it.

.NET 8 should be hitting this autumn. In the meantime, the preview versions are being released so you can try them out and see what migration issues you run into.

[JohnHDev]

@hartez Can you add the regression label to this as this worked previously in .NET 7. I would think regressions are always backported, but I don't want to assume anything when it comes to .NET Maui.

I would also suggest you reopen my bug report until it has been merged into .NET 7, as that is the version that the bug was found.

[JohnHDev]

Just watched https://www.youtube.com/watch?v=arxsDF__uFA.

So not only is @davidortinau aware of this process of fixing in .NET 8 (a version in beta) and then considering merging back into .NET 7 (you know, the production version of your code that everyone uses) he mentioned it is the official MS process.

So as of writing, it could be 5-6 months before we see some production fixes. I clearly disagree with this approach, MS is ignoring its customers issues and fixing them in a version we cannot use. No, we are not going to waste our time 'trying out a beta version of .NET'.

Long story short, we are no longer considering migrating to .NET Maui at this time but we will take another look in November with the release of .NET 8. I manage a team of 9 Xamarin developers, I cannot in good conscience allocate anyone to look at .NET Maui in its current state.

Please consider extending Xamarin Forms support for a further 6 to 12 months.

[Inrego]

Also want to add that this is a regression. Grids were working fine in .NET 7. Then I updated Visual Studio and now everwhere the app looks like shit. I've spent hours upon hours trying to come up with workarounds to no avail. Being that it's so slow to build and deploy debug builds for iOS (#14560) it's really tedious.

[hartez]

/backport to net7.0

[github-actions]

Started backporting to net7.0: https://github.com/dotnet/maui/actions/runs/5138948244

[github-actions]

@hartez backporting to net7.0 failed, the patch most likely resulted in conflicts:

$ git am --3way --ignore-whitespace --keep-non-patch changes.patch

Applying: [iOS] Don't set constrains for orientation if they are 0
Using index info to reconstruct a base tree...
M	src/Core/src/Handlers/ScrollView/ScrollViewHandler.iOS.cs
Falling back to patching base and 3-way merge...
Auto-merging src/Core/src/Handlers/ScrollView/ScrollViewHandler.iOS.cs
CONFLICT (content): Merge conflict in src/Core/src/Handlers/ScrollView/ScrollViewHandler.iOS.cs
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 [iOS] Don't set constrains for orientation if they are 0
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

[github-actions]

@hartez an error occurred while backporting to net7.0, please check the run log for details!

Error: git am failed, most likely due to a merge conflict.